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

[Michael Niedermayer]

Hi

On Wed, Apr 04, 2007 at 04:53:00AM +0300, Uoti Urpala wrote:
> 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, 

ill remember uoti-pic = no relocations, thanks for the clarification

for me pic still means few relocations so that 99% of the code can be
shared compared to non pic with shit loads of relocations where very
little can be shared and loading due to many relocs is slow
(thats what practically matters ...)


> 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? 

in the common sense

that is you execute it and it gives the output expected ...


> 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_.

AMD64? i think what you are trying to say is the redhat-gnu toolchain on
x86-64 doesnt support relocations properly they could as well have choosen
not to support it on any other arbitrary architecture or support it on
x86-64 ... (and yes iam not too familiar with the x86-64 toolchain related
bugs and limitations either)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070404/3c77c4e5/attachment.pgp>