Jevin Sweval <[email protected]> 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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
