[Ffmpeg-devel] Re: Broken trunk on AMD64 with PIC enabled

[Uoti Urpala]

On Wed, 2007-04-04 at 02:46 +0200, Michael Niedermayer wrote:
> On Wed, Apr 04, 2007 at 01:03:29AM +0200, Diego 'Flameeyes' Petten? wrote:
> > On Wed, 04 Apr 2007 01:35:07 +0300
> > Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > 
> > > Note that shared libraries are required to be PIC on AMD64, so no PIC
> > > means no shared libraries either.
> > 
> > Exactly. This is why I thought it was important to let you know it
> > doesn't build.
> > 
> > For what it's worth, while I'm still trying to understand how inline
> > asm works (I said already, I have no clue about it and I don't pretend
> > to pass like I have some), I'll be working locally on xine with the
> > attached patch applied. As Trent Piepho said, there's no way the
> > references in that code would be PIC-compatible, and at least this much
> > I think I understand.
> 
> you understand but Trent Piepho seems to be wrong, the references are
> PIC-compatible its a problem of relocations with the assembler/linker/loader
> on x86-64

PIC means no relocations (that's the point of the definition, code which
does not need to be modified by the linker depending on location). So
requiring PIC means you cannot make the runtime linker do relocations in
shared library code, and AFAIK that is the case on AMD64 (though I'm not
too familiar with the subject).

> on x86-32 ive just tried
> 
> -----
> int table[4]={1,2,3,4};
> 
> void test(void){
>     int range, ret;
> 
> for(ret=0; ret<16; ret++){
>     asm volatile ("movzbl table(%1, %2, 2), %0"
>         : "=r"(range)
>         : "r"(ret), "r"(0));
> printf("%d ", range);
> }
> }
> -----
> 
> and it worked fine with -DPIC -fPIC -shared -Wl,-shared

Worked fine in what sense? If you mean you could create a shared
library, then yes x86-32 does allow shared libraries to be non-PIC and
have relocations. However the point about AMD64 is that the requirements
_differ_.

If you compile the above and check the resulting file with objdump -r,
the result contains

00000026 R_386_32          table

AFAIK you could not add an object containing this type of relocation to
a shared library on AMD64.