*but* for some reason it doesnt seem to work with libxul.so, which is
where most of the symbols of the engine lies.
At the beginning i thought it was an issue as libxul.so is dlopen()'ed
by firefox binary (and not linked in the binary) but in some trunk
builds i have around, libnss3 & libnspr4 are also dlopen()'ed by firefox
binary and ltrace still shows symbols from those libs, so that doesnt
seem an issue with dlopen().
objdump -p /usr/local/lib/firefox/libxul.so.85.0 |grep NEED lists all
the dependencies of libxul, and i have no issue showing called symbols
from those via ltrace, ie ltrace -i -ulibcairo /usr/local/bin/firefox
yields many things.
So, what could be the issue here ? the symbols i expect being called by
the code are not all exported in libxul.so ? The library is too large
(250mb)? I find it strange that
ltrace -i -ulibxul /usr/local/bin/firefox
yields nothing while most of the actual code is there.
Re: ltrace fails to display symbols for huge libraries ?
On Wed, 6 Nov 2019, Landry Breuil wrote:
> playing with ltrace, trying to see what functions are called by firefox,
> it works fine in many situations:
> ltrace -i -ulibnspr4 /usr/local/bin/firefox
> ltrace -i -u:NSS* /usr/local/bin/firefox
> *but* for some reason it doesnt seem to work with libxul.so, which is
> where most of the symbols of the engine lies.
ltrace works via a hook in _dl_bind(), the lazy-binding entry point. If
something doesn't go through _dl_bind(), then ltrace won't see it.
_dl_bind() is only invoked for references through a PLT entry, but dlsym()
always returns the real function address and never the address of the PLT
entry, so calls through the pointer returned by dlsym() will never
generate an ltrace record.
I've played a bit with trying to convince dlsym() to return the address of
a PLT entry for a function, but the set of circumstances where that would
work are _really_ limited and depend on both the 'handle' argument to
dlsym() and what objects contain a PLT entry for the target function.
I haven't investigated how other OSes handle ltrace vs dlsym; the current
ltrace design relying on PLT just seems too limited to get anywhere close
to useful functionality.