[Ffmpeg-devel] Re: Broken trunk on AMD64 with PIC enabled
Wed Apr 4 11:20:07 CEST 2007
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
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
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
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel