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

[Michael Niedermayer]

Hi

On Tue, Apr 03, 2007 at 08:48:16PM -0700, Trent Piepho wrote:
> On Wed, 4 Apr 2007, Michael Niedermayer wrote:
> > On Wed, Apr 04, 2007 at 01:03:29AM +0200, Diego 'Flameeyes' Petten? wrote:
> > > 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
> 
> No, in this case Michael Niedermayer seems to be wrong.  There is a
> difference between PIC code and code that can be put in a DSO.  Code that
> uses TEXTRELs is not pic, but can still (on ia32) be put in a DSO.

fine if the generally accepted definintion of PIC is that strict ill accept
that
ive already said i ve no time ATM (yeah google soc ...) for this disscussion
which is likely why you and uoti continue it instead of providing any useable
help in correcting the problem (that is a patch we can apply ...)


[...]
> On x64-64, TEXTRELs are much more problematic and in general *can't be
> used*.  This is not a limitation of the GNU toolchain, but a limitation of
> the AMD64 instrunction set, and exists on non-GNU OSes too.
> 
> The displacement field in the movzbl instruction, where the address of
> 'table' should be written, is only 32-bits.  On x86-64 the address space is
> 64-bits!  How can a 64-bit address be loaded into a signed 32-bit
> displacement field?  It can't!

hmm i didnt know that x86-64 is that missdesigned ...
but i must admit that i have difficulty imaging a situation where a single
process would need more than 4gb of shared libs or actually more than 4gb
of static/global data for used shared libs

of course this might become a problem one day but currently it looks quite
unrealistic ...

also rip relative is also limited to 32bit offsets ...

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

There will always be a question for which you do not know the correct awnser.
-------------- 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/546f24c6/attachment.pgp>