[Ltrace-devel] DWARF prototypes: handling symbol aliases

Dima Kogan lists at dima.secretsauce.net
Sat Jul 12 00:46:38 UTC 2014


Petr Machata <pmachata at redhat.com> writes:

> Dima Kogan <lists at dima.secretsauce.net> writes:
>
>> I also just discovered that this new symbol aliasing code works with
>> 'ltrace -l', but not any of the other filtering options. I'll take a
>> look when i have time; hopefully by next week.
>
> OK.  Let me know when you are happy with the code.

I fixed this, and the tree now has another patch. The issue was that the
export list (which I use for the alias resolution) was only being built
for -l, but not for -e or -x. This patch always builds this list, being
careful to not make any other behavioral changes.

I now have a separate variable to control whether we should activate
latent symbols or not; previously the existence of the export list was
used to make this determination.

Furthermore populate_this_symtab() now takes an extra argument to
indicate that ONLY the export list should be filled in.

With this patch, I can see the calls from the following program with -l,
-e or -x:

 #include <stdio.h>
 #include <stdlib.h>
 #include <stdint.h>
 void main(void)
 {
     usleep(33);
     nanosleep(&(struct timespec){.tv_nsec = 44}, NULL);
 }


I did find another corner case, which I don't think is related to my
tree. If I build this same application with pthread support then I still
don't see the prototype when ltracing with -x:

 $ gcc -pthread -o /tmp/tst /tmp/tst.c && ./ltrace -L -x '*sleep' /tmp/tst

 usleep at libc.so.6(33 <unfinished ...>
 nanosleep at libc.so.6({ 0, 33000 }, nil)                                 = 0
 <... usleep resumed> )                                                 = 0
 nanosleep at libpthread.so.0(0x7fff57574e70, 0, 0, -1)                    = 0
 +++ exited (status 0) +++

This somewhat makes sense: the nanosleep being called in this case lives
in libpthread.so, not in libc6.so; and for some reason in Debian the
debug symbols of libpthread.so have nothing about nanosleep (or
__nanosleep, etc). But if this is so, then why does it work with -e and
-l? Does it make sense to you? In any case, this wrinkle probably is
independent of my changes, and it'd be great if you reviewed the tree.

Thanks
dima



More information about the Ltrace-devel mailing list