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

[Michael Niedermayer]

Hi

On Thu, May 10, 2007 at 10:09:04PM -0700, Trent Piepho wrote:
> On Thu, 10 May 2007, Rich Felker wrote:
> > > On Wed, May 09, 2007 at 03:32:11PM -0700, Trent Piepho wrote:
> > > On Wed, 9 May 2007, Rich Felker wrote:
> > > > > On Wed, May 09, 2007 at 03:57:01PM +0100, M??ns Rullg??rd wrote:
> > > > > Rich Felker wrote:
> > > > > > Nope, this is not true. Rather, without PIC, relocations remain inline
> > > > > > in the code rather than isolated to GOT/PLT tables. This means that
> > > > > > the dynamic linker must modify large amounts of code at startup
> > > > > > (runtime), resulting in unsharable pages and bad initial performance.
> > > > > > However it in no way precludes relocation.
> > > > >
> > > > > On x86_64 it does, at least in the general case.  A 32-bit immediate operand
> > > > > might need 64 bits after relocation.  Theoretically, the compiler could have
> > > > > a flag telling it to make all relocatable values 64-bit, but gcc doesn't to
> > > > > my knowledge have such an option.
> > > >
> > > > This is a bug in the assembler..
> > >
> > > How do you solve this?  The x86-64 ISA only allows for 32-bit displacements
> > > in addresses and (in general) 32-bit immediate operands.
> > >
> > > I do not understand how you can do a 64-bit relocation on a 32-bit field.
> >
> > There's no opcode variant with a 64bit value? Sorry I don't know
> > x86-64 asm so I don't know how to fix it.
> 
> There's no opcode variant for 64-bit displacements.  The mod field in the
> ia32/x86-64 operand format is 2-bits.  0 = no displacement, 1 = one byte
> displacement, 2 = 32-bit displacement, 3 = operand is register, not memory
> address.
> 
> In x86-64, this isn't changed.  There is no option for a 64 bit displacement.

yes, if you have more then 2^32 of something to address then x86-64 will have
its problems with that no relation to PIC here
if all the libs a process needs fit in 2^32 then everything is fine (in
theory, that is it is easyly possible but the loader doesnt do it)

if a single lib doesnt fit in 2^32 then things cannot be addressed with
displacements but the address rather has to be build by loading a 64bit
constant into a register, this iam sure you will agree can be relocated
to any 64bit address


> I imagine that AMD figured out that making displacements 64 bits instead of 32
> bits was a net loosing proposition.  Using position independent code when
> necessary is probably faster than bloating all code with 64-bit displacements

as if PIC was anything else then bloating all the code with 64bit displacements
they are just stored in the GOT and need an extra indirection and extra register
to be read
(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
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)


> so text relocations are possible.  Even on ia32, were no instruction bloating
> is necessary, PIC is almost always better than text relocations.

its as much better as 10% fewer registers and 2x slower memory accesses due to
the double indirection over the GOT


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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/20070511/cbd1afc4/attachment.pgp>