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

So you're basically saying that calling PIC code from non-PIC code
doesn't work reliably, and that you're fine with that?

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

Yes.  At the very least, such options should be clearly documented as
violating the standard, and when possible, a warning should be issued
whenever this happens.

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