[Ltrace-devel] [PATCH 0/1] Attempt to fix libdl tracing when attaching to PIDs

Petr Machata pmachata at redhat.com
Sat Mar 23 01:16:43 UTC 2013


Petr Machata <pmachata at redhat.com> writes:

> Would you mind sending me your libm.so binary privately?  Chances are
> I'll be able co reproduce the problem with it, distill a test case, etc.

The problem is that your libm has several IFUNC symbols that are called
internally.  This produces IRELATIVE relocations in .rela.plt.  Such
relocations don't have a symbol assigned, which is why ltrace shows
these as empty strings.  IRELATIVE relocations work like this:

  indirect(A + B)

I.e. take addend, add it to base (where the library was mapped), and the
result is an address of a function that, when called, returns the
address of the actual symbol.  So we need to do something similar: we
take addend, and look for a symbol with the same address.  If we find
it, then that's the name associated with this PLT slot.  Otherwise we
just make something up (currently there's ifunc at 0xaddress).

The code for this is on pmachata/irelative.  It needs platform
cooperation: backends need to know about IRELATIVE relocations and check
for them.  Currently only x86_64 is known to work well.  I'll work
through backends that I have handy (ARM, PPC, IA64, s390) and
incrementally enable what works.

There are two test cases: one where the IFUNC symbols are in the main
binary itself, and another, where they are in a shared library.  For
some reason, I can't make the latter work on i386.  It just sigsegvs for
me.  Either I'm doing something wrong, or the 386 dynamic linker doesn't
support this.

Note that tracing IFUNC symbols themselves (i.e. by -x) is not supported
at all.  Only IRELATIVE PLT tracing is.

Comments welcome.

Thanks,
PM



More information about the Ltrace-devel mailing list