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

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

> just to clarify this, with
> global i of course meant global on one system not global for the world or
> distribution

I figured that's what you meant, although with a 64-bit address space
even truly globally unique addresses would be theoretically possible.
In practice there would of course be the problem of coordination.
Besides, no current CPUs have a full 64-bit address space.

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