[Ffmpeg-devel] Re: [PATCH] Fix compilation when using --disable-opts
Sun Apr 1 14:53:32 CEST 2007
Michael Niedermayer <michaelni at gmx.at> writes:
> 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.
mans at mansr.com
More information about the ffmpeg-devel