[FFmpeg-devel] Memory leak using bitstream filters with shared libs

[Måns Rullgård]

Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> On Sun, 2008-03-09 at 14:14 +0100, Michael Niedermayer wrote:
>> On Sun, Mar 09, 2008 at 06:37:01AM +0200, Uoti Urpala wrote:
>> > Any attempt to make -Bsymbolic also change the addresses seen by
>> > a non-PIC main program would need to involve things like adding
>> > relocations to be done at runtime to the main program code with values
>> > depending on shared library contents...
>> 
>> Curently AFAIK the address is written in the PLT or the PLT reads it
>> from the GOT in the case you describe, thus
>
> PLT has "jmp *X". Initially the value at X points to a function to do
> runtime lookup for the function in question. When called for the first
> time this function writes the lookup result at X.
>
> It would be slightly faster to have a direct jump "jmp Y" in the PLT
> instead (and modify the value Y in the code), but this is not done to
> avoid having a writable+executable memory area.

Why can't the code that takes the address of a function get it from
the GOT instead of returning the address of the PLT entry?  The only
requirement for this to work would be forcing any functions whose
addresses are taken to be resolved at load time.  There is no need for
modifying code areas at runtime at all.

>> > The (at least somewhat) practical alternatives I can think of are:
>> > 1. Accept that addresses inside and outside the library will not match
>> > 2. Stop using -Bsymbolic (you can still use visibility to bind
>> > non-public symbols inside the library)
>> > 3. Compile everything with -fPIC, even the program using the library
>> 
>> True, these are the things we can do still i consider these workarounds of
>> a bug in binutils.
>
> Can you even specify what "less buggy" behavior would be and how it
> would differ?

Taking the address of function should give the same result everywhere,
regardless of compiler/linker flags.  Anything else is in violation of
the C standard.

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