[FFmpeg-devel] Why 'You can only build one library type at once on MinGW'?
Sun May 13 08:10:16 CEST 2007
On Sat, 12 May 2007, Rich Felker wrote:
> On Sat, May 12, 2007 at 08:01:30PM -0700, Trent Piepho wrote:
> > But it remains that x86-64 can't use text relocations unless you are
> > somehow able to entirely give up the 64-bit address space.
> False. The compiler just needs to generate code that loads a 64bit
> immediate and uses it as an address for every single memory access,
> and appropriate relocation records for these. Yes this is rather
> inefficient and ugly, but that's the only way to solve the "problem"
> if the platform is so broken.
If you want to do that, you could just use rip relative addressing to load
the 64-bit base address. It's a smaller instruction and doesn't require a
movq $0x0102030405060708, %rdx # constant must be changed by textrel
movl (%rdx), %eax
leaq 0x01020304(%rip), %rdx # link time constant, no textrel
movl (%rdx), %eax
movl 0x01020304(%rip), %eax # link time constant, no textrel
The only problem is that one cannot combine rip-relative addressing and SIB
addressing. But using a 64-bit immediate mov and a text relocation doesn't
allow that either! It's too bad AMD didn't just use a bit in the REX
prefix to indicate rip relative and still allow all adressing modes, but
they only had so many bits and it would have made address generation more
The only point of using 64-bit relocations would be if you want to allow a
single object to be larger than 4GB. Otherwise using rip relative
addressing allows for a smaller and faster code sequence _and_ avoids the
need for a text relocation.
> > No, I mean a different DSO. If the compiler knows a global variable is
> > going to be located in the same DSO, it can emit a PIC sequence to access
> > it that just involves an extra register to hold the base address. If the
> > compiler does not know if the variable will come for the same DSO or not,
> > it will emit a slower sequence with an extra indirection.
> And a _C_ compiler cannot know. A compiler for a proprietary C-like
> GNU language which is not C can of course know...
> > The ELF default is that non-static global variables may come from different
> > DSOs. This is perhaps an unfortunate choice.
> Unfortunate but absolutely necessary to correctly implement the C
Strange you would say that. a.out doesn't allow for shared libraries to do
that and it's one of the reasons that a.out is faster than ELF. Sounds
like your saying that a.out shared libraries aren't a correct
implementation of the C language.
More information about the ffmpeg-devel