[Ltrace-devel] [PATCH 0/1] Attempt to fix libdl tracing when attaching to PIDs
Joe Damato
ice799 at gmail.com
Tue Mar 19 23:26:29 UTC 2013
On Tue, Mar 19, 2013 at 9:55 AM, Petr Machata <pmachata at redhat.com> wrote:
> Joe Damato <ice799 at gmail.com> 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 at 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 at ubuntu:~/code/ltrace$ /tmp/test/usr/local/bin/ltrace -x acos -p 2840
acos at libm.so.6(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20130319/f9da4a1d/attachment.html>
More information about the Ltrace-devel
mailing list