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

[Michael Niedermayer]

Hi

On Sat, May 12, 2007 at 08:50:44PM -0700, Trent Piepho wrote:
> 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?

what exactly are you trying to show me here? that i disagreed with something
that was orignally from you? thats the claim to which you reply ...

iam also curious why you dont provide links to the technical quotes which
you claimed in past mails where from me


> > > 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

our theoretical toolchain does not generate this from C code, and my claim
was about c code as you can sure see if you read what you quote


[...]

> 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?

no my version is identical to yours, considering the additional restrictions
its ironic that you proofed yourself that the example can be compiled
to 64bit relocateable code on x86-64, even more ironic is it that the code
you choose does not need any relocation


> 
> > > 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.

you dont seem to understand how memory allocation or virtual memory works
let me just proof you wrong
lets say our example app would use 100 out of 1000 .so 
the fragmentation is equivalent to the app allocating 1000 blocks of memory
and then freeing 900, do you think that will make loading anything else
for which there is more than enough memory available impossible?


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

i have 130mb of *.so on /usr, i will not run out of address space, not
even physical ram if i would load them all at once
and iam running a normal distribution which contains enough bloatet
apps ...

actually i think that the idea of loading all .so during system boot isnt
that bad, with todays harddisks its a matter of 10sec to load them assuming
they are put into a single non fragmented .tar and at runtime the
kernel can page unused .sos out to disk
now the 10sec load delay can be trivially avoided by simply using load
on access pages ...


> 
> 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.

to me it sounds like it cant be used if the relative address exceeds a signed
2^32 integer (which is the only sane interpretation if you would know x86-64
asm)


> 
> > 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.  

it is NOT required
_please, please, please_ learn that there is a difference between an
implementation (GNU/Linux) and the standard (C) / architecture (x86-64)


> And a PIC object using rip relative addressing
> will be able to be loaded above 4GB.

which is unrelated to the text you quote


> 
> > > 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.

see non ELF DSO for examples on how much the double indirection is needed
for accesses between 2 DSOs

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20070513/ab748cb9/attachment.pgp>