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

[Petr Machata]

Jevin Sweval <jevinsweval at gmail.com> writes:

> 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?

Yes, I suppose with modern GUI apps, the number of DT_NEEDED entries can
easily exceed 100.  I didn't think about that when writing the cut-off.
I would accept such 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!

Cool!

> 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.

That makes sense as well.  Our DejaGNU scripts actually export
LD_LIBRARY_PATH so that the traced binary finds the testsuite library
that it needs.  It would be cleaner if they just used -E as you propose,
so that the user could override LD_LIBRARY_PATH for ltrace itself.

> 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. =)

That's how I do much of my porting.  I just stare into gdb and objdump
long enough that I understand what's happening.  Another possibility is
killing the traced binary with -SEGV.  It dumps core, which you can
inspect with objdump and look into e.g. what values were written to GOT,
where the breakpoints actually are, etc.

Thanks,
PM