Petr Machata <[email protected]> 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@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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
