[Ffmpeg-devel] Re: [PATCH] Fix compilation when using --disable-opts

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Sun, Apr 01, 2007 at 12:41:56PM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > Hi
>> >
>> > On Sun, Apr 01, 2007 at 01:03:46PM +0200, Michael Niedermayer wrote:
>> > [...]
>> >> > 
>> >> > at least cabac.h, line 388
>> >> > "movzbl "MANGLE(ff_h264_lps_range)"(%0, %%ebx, 2), %%esi\n\t"
>> >> > and line 395
>> >> > "movzbl "MANGLE(ff_h264_lps_range)"("ret", "range", 2), "range" \n\t"\
>> >> > 
>> >> > No way to make ff_h264_lps_range RIP-relative as needed to allow
>> >> > for PIC at least on AMD64 it seems. At least that is my understanding of
>> >> > the issue so far.
>> >> 
>> >> i always thought the broken shared lib loading used on linux these days
>> >> can do relocations ...
>> 
>> Just why is this so broken anyway?  I don't consider having the option
>> to be broken as long as I'm not forced to use it.
>
> its broken because its slow and complex ...

Relocations are only slow if you use them, or are you saying the
dynamic linker is inherently slow for all libs?

>> >> anyway there are 3 obvious ways this code can be generated
>> >> (indpendant of asm vs. c)
>> >> 1. use relocations (fast execution, slow loading, 
>> >>    wastes some possibly alot of memory)
>> >> 2. use extra instructions (slow execution and this is
>> >>    speedcritical code, wastes memory but less)
>> >> 3. use a global unique address for each shared lib (fast and
>> >>    wastes no mem, also avoids all the other PIC overhead ...)
>> 
>> How would you ensure uniqueness between independently built libs?  I
>> know some systems, e.g. Solaris, keep map files in /usr/lib so the
>> linker can pick a free address range.  The problem with this is of
>> course that it falls down if you install libs in other locations.
>
> i really dont see a problem here, what you say is like malloc() having
> problems picking a free address space ...
> in my idea the address where a lib is loaded is not fixed in the binary
> of the lib (that would have security implications ...) but rather that
> the loader/kernel decides once for each lib where it shall be loaded and
> then keeps using this address for the lib for all processes until shutdown
> or until the lib becomes systemwide unused

OK, I see what you mean now.  This would still require either PIC or
text relocations though.

-- 
M?ns Rullg?rd
mans at mansr.com