[Ltrace-devel] Work on bug #135985 - ltrace could catch library-to-library calls

[Jevin Sweval]

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 <pmachata at redhat.com> wrote:

> Jevin Sweval <jevinsweval at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20140204/d880065d/attachment.html>