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

Rich Felker dalias
Sun Mar 9 20:37:44 CET 2008

On Sun, Mar 09, 2008 at 08:52:37PM +0200, Uoti Urpala wrote:
> On Sun, 2008-03-09 at 18:35 +0000, M?ns Rullg?rd wrote:
> > 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.
> That IS what happens in PIC code. The issue that started this thread
> happened because there was non-PIC code using the address in the
> process. I already explained in reply to your earlier mail that the code
> generated for ffmpeg.c ("movq   $0x4038a0,0x48(%rsp)") writes a direct
> value that is included in the assembler instruction itself. You need to
> use -fPIC if you want the compiler to generate extra indirection through
> the GOT.

If the code is non-PIC then the 0x4038a0 in the library needs to be
patched at runtime anyway to account for the library load address. No
harm would be done by the linker generating the correct type of
relocation instead of the incorrect (fixed offset from load address)
relocation it's generating now.

> > 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.
> What's your point here? You think a compiler or linker must not have
> flags like -Bsymbolic that can generate behavior different from the C
> standard?

I think it's wrong to have such flags especially when not documenting
them as such, and when the sane behavior of the flag would not
conflict with the standard.

-Bsymbolic should be (and should be understood) as follows:

"Make link-time optimizations that are possible based on the
requirements the C language places on strictly-conforming programs,
disabling overhead that is needed for non-conformant programs relying
on ELF symbol resolution semantics."

This "should" is purely a moral judgement so I'm uninterested in
Uoti's ideas contrary to it.


More information about the ffmpeg-devel mailing list