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

Michael Niedermayer michaelni
Sun Apr 1 14:46:34 CEST 2007


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


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

of course i could have missed some issues here ...

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20070401/d009a8a6/attachment.pgp>



More information about the ffmpeg-devel mailing list