ltrace fails to display symbols for huge libraries ?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ltrace fails to display symbols for huge libraries ?

Landry Breuil-5
Hi,
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.

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().

/usr/local/bin/firefox:
        Start            End              Type  Open Ref GrpRef Name
        000013c3e0300000 000013c3e0353000 exe   2    0   0 /usr/local/bin/firefox
        000013c68ce1b000 000013c68cef7000 rlib  0    1   0 /usr/lib/libc++.so.3.0
        000013c6451ec000 000013c64522e000 rlib  0    2   0 /usr/lib/libc++abi.so.1.0
        000013c6a1986000 000013c6a1993000 rlib  0    1   0 /usr/lib/libpthread.so.26.1
        000013c6d5491000 000013c6d54c0000 rlib  0    1   0 /usr/lib/libm.so.10.1
        000013c6987e5000 000013c6988d9000 rlib  0    1   0 /usr/lib/libc.so.96.0
        000013c696dba000 000013c696dba000 ld.so 0    1   0 /usr/libexec/ld.so

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.

Thanks for any pointers.

Landry

Reply | Threaded
Open this post in threaded view
|

Re: ltrace fails to display symbols for huge libraries ?

Philip Guenther-3
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.


Philip