Thanks for the info, Petr. Sorry for my delay in replying, I wanted to investigate the issues I was seeing more before I responded.
I was originally using version 0.5 from the Ubuntu repo. I built 0.7 from source and was able to get library to library tracing working on a simple test program. I couldn't get it to work for the library that I really wanted to trace. Turns out there were 122 entries in the .dynamic table! This line is that caused me so much confusion: https://bitbucket.org/jevinskie/ltrace-p/src/master/sysdeps/linux-gnu/proc.c#cl-335I'd suggest increasing that limit (to, say, 10k) and emit an error or warning when that limit is reached. Should I submit a patch? After increasing the limit and realizing that I needed to use '-l <lib name>' instead of '-l @<lib name>', tracing works great! Awesome! I also added an --env-var/-E VAR=VALUE option to inject environment variables into the process that ltrace launches. The option can be specified more than once. I wanted this option so that I could use LD_PRELOAD without injecting into ltrace itself. I can clean up the patch and add some test cases (I'm learning DejaGNU!) if you think it would be appropriate to upstream. Thanks for your help, Jevin P.S. I single-stepped through a library to library call with GDB and saw how there are separate PLT tables for the executable and libraries. Horray for learning. =) On Thu, Jan 30, 2014 at 7:27 PM, Petr Machata <[email protected]> wrote: > Jevin Sweval <[email protected]> writes: > > > This is a feature that I would really like to see! I'm not sure where > > to start working though. > > This should generally work in ltrace 0.7.0 or later. Use ltrace -e@ to > tell ltrace that you want to trace calls from all libraries (the empty > string before the @ means "all symbols", the empty string after @ means > "all libraries". Check out man for more elaborate syntax). -n sets > indentation so that it's clearer what's happening: > > $ ltrace -e@ -n1 echo > echo->__libc_start_main([ "echo" ] <unfinished ...> > echo->getenv("POSIXLY_CORRECT") > = nil > echo->strrchr("echo", '/') > = nil > echo->setlocale(LC_ALL, "" <unfinished ...> > libc.so.6->malloc(5) > = 0x187a010 > libc.so.6->free(0x187a010) > = <void> > [... etc ...] > > Note that the method of tracing that ltrace uses has a very high > overhead. Using e.g. python in this regime is an interesting > contemplative exercise--it takes minutes before you see the prompt and > then every character you write produces a sputter of log messages. > > > I don't understand Juan's comment [0] about how libc6 libraries don't > > use the executable's PLT (do they use their own?). I would greatly > > appreciate any pointers! > > Each library has its own set of PLT slots through which it calls to > other libraries. Formerly ltrace only cared about the PLT slots in the > main executable. The missing functionality was added in 0.7.0. > > Thanks, > PM >
_______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
