<div dir="ltr"><div><div><div><div>Thanks for the info, Petr. Sorry for my delay in replying, I wanted to investigate the issues I was seeing more before I responded.<br><br>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: <a href="https://bitbucket.org/jevinskie/ltrace-p/src/master/sysdeps/linux-gnu/proc.c#cl-335">https://bitbucket.org/jevinskie/ltrace-p/src/master/sysdeps/linux-gnu/proc.c#cl-335</a> I'd suggest increasing that limit (to, say, 10k) and emit an error or warning when that limit is reached. Should I submit a patch?<br>
<br></div><div>After increasing the limit and realizing that I needed to use '-l <lib name>' instead of '-l @<lib name>', tracing works great! Awesome!<br></div><div><br></div>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.<br>
<br></div>Thanks for your help,<br></div>Jevin<br><br></div>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. =)<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 7:27 PM, Petr Machata <span dir="ltr"><<a href="mailto:pmachata@redhat.com" target="_blank">pmachata@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Jevin Sweval <<a href="mailto:jevinsweval@gmail.com">jevinsweval@gmail.com</a>> writes:<br>
<br>
> This is a feature that I would really like to see! I'm not sure where<br>
> to start working though.<br>
<br>
</div>This should generally work in ltrace 0.7.0 or later.  Use ltrace -e@ to<br>
tell ltrace that you want to trace calls from all libraries (the empty<br>
string before the @ means "all symbols", the empty string after @ means<br>
"all libraries".  Check out man for more elaborate syntax).  -n sets<br>
indentation so that it's clearer what's happening:<br>
<br>
$ ltrace -e@ -n1 echo<br>
echo->__libc_start_main([ "echo" ] <unfinished ...><br>
 echo->getenv("POSIXLY_CORRECT")                                                                 = nil<br>
 echo->strrchr("echo", '/')                                                                      = nil<br>
 echo->setlocale(LC_ALL, "" <unfinished ...><br>
  libc.so.6->malloc(5)                                                                           = 0x187a010<br>
  libc.so.6->free(0x187a010)                                                                     = <void><br>
  [... etc ...]<br>
<br>
Note that the method of tracing that ltrace uses has a very high<br>
overhead.  Using e.g. python in this regime is an interesting<br>
contemplative exercise--it takes minutes before you see the prompt and<br>
then every character you write produces a sputter of log messages.<br>
<div class="im"><br>
> I don't understand Juan's comment [0] about how libc6 libraries don't<br>
> use the executable's PLT (do they use their own?). I would greatly<br>
> appreciate any pointers!<br>
<br>
</div>Each library has its own set of PLT slots through which it calls to<br>
other libraries.  Formerly ltrace only cared about the PLT slots in the<br>
main executable.  The missing functionality was added in 0.7.0.<br>
<br>
Thanks,<br>
PM<br>
</blockquote></div><br></div>