[FFmpeg-devel] Why 'You can only build one library type at once on MinGW'?

[Rich Felker]

On Sun, May 13, 2007 at 04:51:28PM -0700, Trent Piepho wrote:
> > > Do this:
> > >   leaq 0x01020304(%rip), %rdx     # link time constant, no textrel
> > >   movl (%rdx), %eax
> >
> > Forget about ELF "textrel" terminology. The rip-relative address is
> > not known until the relocation is resolved by the linker. It might not
> > be within 4gig of %rip, and then the linker will fail.
> 
> That's pretty much the same thing as saying objects larger than 4GB aren't
> supported, isn't it?

Yes, and it is entirely practical. It's impossible for humans to make
a program larger than even a few hundred megs of code, much less 4
gigs. The human brain cannot deal with that much complexity, and
should not have to; something that complex should be broken into many
programs.

> You claimed that not supporting text relocations on x86-64 was an assembler
> bug.  It's not an assembler bug, it's a limitation of the architecture.

Indeed, I'm sorry. It's a compiler bug to generate code that way, if
there's any intent that the code could be relocated beyond 4gig.

> If you want to support text relocations on x86-64, without limiting the total
> address range across all objects to 32-bits, you must use an alternate and
> much larger and slower sequence to access global data.  Call this a "long
> access" if you want.

OK.

> Provided one accepts the limitation that a single object must fit in 4GB,

This is not necessary. The compiler deals with a whole object at once,
so it can choose to generate code with "long accesses" if it needs to
for a larger program. But the idea of an object >4gig is pure pedantry
since it does not exist and will never exist.

> there exists an alternative to the "long access", rip-relative addressing,
> that is smaller, faster, and, being position independent, avoids the text
> relocation.
> 
> "long accesses" would allow relocations above 32-bits, but rip-relative
> addressing allows the same thing and is superior in every way.  So, other

It does not allow the same thing. rip-relative addressing cannot
access addresses further away than ?2gig, and it's impossible to know
when the code is generated how far away the address will be, except
for module-local (static linkage) symbols.

> than to allow objects larger than 4GB, what possible reason is there for a
> compiler to support "long accesses"?

I agree, none. Since you've elaborated, it's clear: the bug is that
the dynamic linker loads libraries at inaccessible addresses. If it
loaded them under 4gig like it should then textrels would work just
fine.

> C89 doesn't say anything about inline asm, can that be used?

No, never as the only implementation of something. Only as an optional
optimization for use when compiling on a particular compiler/host
combination.

> C89 doesn't
> say anything about shared libraries or dynamic linking or memory models,
> so any optimization relating to those can't be used?

A good program cannot be dependent on them, no.

Rich