On Tue, Mar 19, 2013 at 9:55 AM, Petr Machata <[email protected]> wrote:
> Joe Damato <[email protected]> writes: > > > I noticed that ltrace was unable to trace symbols from runtime loaded > > dynamic objects when attaching to a PID. I've written a small (and > > ugly) patch to try to fix this. Let met know if there is a better way > > to do this and I'll be happy to make the change and submit a fix. > > Oh, I think it was approximately the right thing. We simply need to do > the same things on attach that we do after hitting _start. I extracted > this to a separate function (process_hit_start), and call it from > open_pid and entry_breakpoint_on_hit. > > Since there is no other way to get on dyn_addr in open_pid anyway, we > simply look for the main library, and read it there, like you did in > your patch. That means we don't need to track that information at entry > breakpoint anymore, and we can get rid of struct entry_breakpoint. > Ah yea, your implementation is much cleaner. Sorry, still finding my way around the codebase again. Been a while. > A test case and this patch are sitting on pmachata/dlattach. Tell me > what you think. > There is something odd happening that I need to investigate a bit more. I've noticed when trying to use ltrace to trace symbols loaded with dlsym, only -x seems to actually work. I think this is because of where and how plt_filter and static_filter are examined in the codebase. I tried to re-arrange them and some surrounding code, but I ended up breaking existing tests for -e. That said, I am confused why this test case appears to pass when I run make check. I wrote a test program that dlopen's libm, and then uses dlsym to find "acos" and calls the function after a short sleep so I can attach ltrace. The test program looks like this: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <dlfcn.h> #include <math.h> int main(void) { void *handle = NULL; double (*acos)(double); printf("my pid: %d\n", getpid()); handle = dlopen("/lib/x86_64-linux-gnu/libm.so.6", RTLD_LAZY); acos = dlsym(handle, "acos"); acos(0.5); sleep(10); acos(0.5); return 0; } I attach ltrace like this and get the following output: joe@ubuntu:~/code/ltrace$ /tmp/test/usr/local/bin/ltrace -e* -p 2821 libm.so.6->(0x7fff07366f90, 0x7fff07366f90, 0, -1) = 0x7f0384fe06a0 libdl.so.2->__cxa_finalize(0x7f038582f078, 0, 0xffffffff, 0x7f038582ed50) = 0x7f0385627350 libm.so.6->(0x7f038526c0c0, 0, 0, 3) = 0x7f0385627350 +++ exited (status 0) +++ It looks like the first line is ltrace tracing the call to acos but not matching the symbol name, for some reason? If, instead I use -x, I see the symbol name: joe@ubuntu:~/code/ltrace$ /tmp/test/usr/local/bin/ltrace -x acos -p 2840 [email protected](0x7fff313a7d10, 0x7fff313a7d10, 0, -1) = 0x7f56e25686a0 +++ exited (status 0) +++ I'm convinced this is due to a bug with how plt_filter, static_filter, populate_plt, and populate_symtab are handled in ltrace, but I haven't had a chance to narrow this down yet. Any idea why I might be seeing this? Do you see the same/similar output? Thanks, Joe
_______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
