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

[Michael Niedermayer]

Hi

On Fri, May 11, 2007 at 01:35:57PM -0700, Trent Piepho wrote:
> On Fri, 11 May 2007, Michael Niedermayer wrote:
> > On Thu, May 10, 2007 at 10:09:04PM -0700, Trent Piepho wrote:
> > > 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
> 
> The situation on x86-64 is that a single library will fit into 4GB.  In fact,
> gcc doesn't support creating objects larger than 4GB.  It is possible to use
> 32-bit displacements with SIB addressing in non-pic, non-relocatable objects.
> In pic objects, it's possible to use 32-bit displacements plus rip relative
> addressing to compute a position independent address without thunking.
> 
> All objects in total may be greater than 4GB, 

but they are not today and when we reach that point we can still switch to PIC
or use 64bit immedeate move to register style


> or may be loaded at an address
> above 4GB even if the total is less.  32-bit displacements still work.

why not just load it only in even bytes and redesign the toolchain to support
that?


[...]
> > > 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
> 
> And not dirtying every single page of the library doing relocations.

the design where you load a library at a different address for every process
is something very sick, hell i dont even know if linux with the current
loader still behaves like that, its simply totally stupid, theres no need
for that at all just give the lib a single systemwide address when its loaded
the first time and you never have to dirty any page ...

and yes your security critical libs can still be loaded at random addresses
security critical libs per definition are not 4gb large ...


> 
> I also suspect you don't know how PIC works on ia32.  There is no double
> indirection.  Once the pic register is loaded, it can be used through an
> entire function, it doesn't need to be re-loaded for each access.
> 
> C code:
> static int last;
> static __attribute__((noinline)) int next(void) { return ++last; }
> 
> non-PIC asm for next:
>   mov    0x2c,%eax
>   inc    %eax
>   mov    %eax,0x2c
>   ret
> 
> PIC asm for next():
>   call   25 <next+0x5>		;\
>   pop    %ecx			;| = load ecx as pic register
>   add    $0x3,%ecx		;/  (only done once per function)
> 
>   mov    0x4c(%ecx),%eax	; code for ++last
>   inc    %eax
>   mov    %eax,0x4c(%ecx)
>   ret

PIC asm without static cheating:
next:
        call    __i686.get_pc_thunk.cx
        addl    $_GLOBAL_OFFSET_TABLE_, %ecx
        pushl   %ebp
        movl    %esp, %ebp
        movl    last at GOT(%ecx), %edx
        movl    (%edx), %eax
        incl    %eax
        movl    %eax, (%edx)
        popl    %ebp
        ret

i hope even someone who doesnt understand how PIC works can see that it does
take the pointer "last" from the GOT and then dereferences it which is
double indirection
this happen because some wise text x86-ABI or ELF or whatever _requires_ it
IIRC

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

There will always be a question for which you do not know the correct awnser.
-------------- 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/6af23f62/attachment.pgp>