[Ltrace-devel] [PATCH 0/1] Attempt to fix libdl tracing when attaching to PIDs

[Joe Damato]

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>