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

[Trent Piepho]

On Sun, 13 May 2007, Michael Niedermayer wrote:
> On Sat, May 12, 2007 at 01:45:13PM -0700, Trent Piepho wrote:
> > On Sat, 12 May 2007, Michael Niedermayer wrote:
> > > On Fri, May 11, 2007 at 07:34:03PM -0700, Trent Piepho wrote:
> >
> > It seems to me the other way around.  You feel a need to disagree with
> > anything I say, even when you don't know much about th subject.
>
> i dont disagree with everything you say, i just disagree where i know you
> are wrong and anyway the things you say are from people like some
> specific gcc developers, ulrich drepper and others, so really i disagree
> with them more than i do with you, you just repeat what they say ...
> i actually dont remember that i ever disagreed with a statement which was
> originally from you

http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/47939/focus=48001

I'm sure I could find more, but would be the point?

> > x86-64's lack of support for textrels is entirely a limitation/bug of the tool
> > chain.  It's not, it's a limitation of the architecture.
>
> and here you are wrong, it is purely a limitation of the toolchain
> we could play a game so i can proof it to you, just give me some simple C
> code and ill give you some theoretically 64bit relocateable x86-64 code

The problem seems to come from the non-pic asm code, so how would the tool
chain solve that problem?

	movzbl table(%rax, %rbx, 2), %edx

How does the assembler/compiler/linker/dyn linker make that work when it's
loaded to an address above 4GB?  My position is that the x86-64 architecture
doesn't allow code like that in a DSO, and there is nothing the toolchain can
do to make it work.

But if you want C, we can do that too:
static int x;
int foo(void) { return ++x; }

So what is the instruction sequence that allows relocations?  I think I
already know what you'll write, so consider that this PIC sequence doesn't
require any relocations:

     movl x(%rip), %eax
     inc %eax
     movl %eax, x(%rip)
     ret

Given that this code is possible, is the version that allows for 64-bit text
relocations better in any way?

> > Loading all DSO's at a system wide fixed address under 4GB is feasible.  I'm
> > not even going to touch that, just post it to lkml.
>
> well you touch it by mentioning, but you provide no arguments so i assume you
> have none

If you do it at run time, you'll memory will get fagmented to the point
where loading more objects quickly becomes impossible.

If you do it once at system boot time, ake pre-linking, you still run out
of address space.

With a 64-bit address space, prelinking becomes possible.

> > x86-64 can't use rip relative addressing to create PIC code.  It can and does,
> > just look at the asm output.
>
> i dont think i said that, what i said was
>
> (note the RIP relative addressing is limited to 2^32 so no it cannot be used,
> an extra register must be used, after all we do speak about the corner case of

Sounds like your saying RIP relative addressing can't be used to me.

> more than 2^32 bit addressing and the compiler does NOT know if the address
> of something after linking will be within 2^32 bit so i dont think it can
> selectively choose RIP relative addressing)

The compiler does know the symbols will link under 4-GB, because it's
required that they do so.  And a PIC object using rip relative addressing
will be able to be loaded above 4GB.

> > Accessing a global variable using PIC code requires double indirection via the
> > GOT.  Not true.  The extra indirection is for accessing a symbol from a
> > different DSO.  PIC only requires the use of an extra register holding the
> > base address in the address calculation.
>
> accessing a global variable using PIC by default does double indirection
> most libs use that default

The indirection isn't because of PIC, it's because the variable could come
from another DSO.  If the compiler knows the variable is from the same DSO,
it can access it in a PIC manner without needing extra indirection.