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

[Uoti Urpala]

On Sun, 2008-03-09 at 19:30 +0000, M?ns Rullg?rd wrote:
> 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?

No. Everything works reliably as long as you don't use -Bsymbolic. Even
if you do use -Bsymbolic calling still works reliably. What -Bsymbolic
makes unreliable is the addresses of objects defined in the library. For
functions code inside the library will see the address of the main
function while code outside the library may see an address in the PLT.
For other variables code inside the library will see the address of the
original variable whereas code outside may see a copy relocation. The
addresses outside can be the same if there is no non-PIC code that
references the symbol.

So basically IF you use -Bsymbolic AND do not compile the main program
with -fPIC then you can only rely on symbols defined in the library to
refer to similarly behaving objects inside and outside, not necessarily
to refer to the same object at the same address.