Re: how to solve a non pic code in an shlib due to assembly code

[Ove Kaaven <ovek@arcticnet.no>]

Goswin von Brederlow skrev:
> Ove Kaaven <ovek@arcticnet.no> writes:
> 
>> However, if they can't or won't fix it, there's *some* good news. In
>> general, shared libraries must be compiled as PIC because on some
>> platforms, the library just won't work properly if you don't. However,
>> i386 and amd64 are not among those platforms. Since the MMX code is only
>> compiled for those, it might be safe to ignore the lintian error in this
>> particular case, if there's no other way.
> 
> Slight correction for the books. No insult intended. Amd64 is verry
> much among those. You usualy end up with a 4 byte offset that is
> computed at runtime link time. But with a shared library there is no
> garanty that the offset will fit in 4 bytes and during compile time
> the linker will complain about a 32bit offset being used where 64bit
> might be needed. Sorry, don't know the exact error message by hard.

I suppose I haven't used the amd64 instruction set enough yet (never had
any excuse to do so yet). However, I've seen that, unlike i386, amd64
does have a PC-relative addressing mode. I'd assume the assembler would
usually use it to try to avoid these problems.

Reviewing the documentation, you have a point in that you probably need
to use amd64 addressing forms that allow this in order for the assembler
to be able to do the right thing. Perhaps the C compiler generally don't
if you don't use -fPIC. But the asm code used here seems to only use
constant displacements when loading memory addresses, which means the
assembler should be able to emit PC-relative addresses automatically, if
it knows what's good for it. And this *should* also go for any other
well-written amd64 asm code out there (even if written for Windows).

And so my excuse is that I was only concerned about the asm code...