<div dir="ltr">On Tue, Mar 19, 2013 at 9:55 AM, Petr Machata <span dir="ltr"><<a href="mailto:pmachata@redhat.com" target="_blank">pmachata@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Joe Damato <<a href="mailto:ice799@gmail.com">ice799@gmail.com</a>> writes:<br>
<br>
> I noticed that ltrace was unable to trace symbols from runtime loaded<br>
> dynamic objects when attaching to a PID. I've written a small (and<br>
> ugly) patch to try to fix this. Let met know if there is a better way<br>
> to do this and I'll be happy to make the change and submit a fix.<br>
<br>
</div>Oh, I think it was approximately the right thing. We simply need to do<br>
the same things on attach that we do after hitting _start. I extracted<br>
this to a separate function (process_hit_start), and call it from<br>
open_pid and entry_breakpoint_on_hit.<br>
<br>
Since there is no other way to get on dyn_addr in open_pid anyway, we<br>
simply look for the main library, and read it there, like you did in<br>
your patch. That means we don't need to track that information at entry<br>
breakpoint anymore, and we can get rid of struct entry_breakpoint.<br></blockquote><div><br></div><div style>Ah yea, your implementation is much cleaner. Sorry, still finding my way around the codebase again. Been a while.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A test case and this patch are sitting on pmachata/dlattach. Tell me<br>
what you think.<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>That said, I am confused why this test case appears to pass when I run make check.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>The test program looks like this: </div><div style><br></div><div style><div>#include <stdio.h></div><div>#include <stdlib.h></div><div>#include <unistd.h></div><div><br>
</div>
<div>#include <dlfcn.h></div><div>#include <math.h></div><div><br></div><div>int</div><div>main(void)</div><div>{</div><div> void *handle = NULL;</div><div> double (*acos)(double);</div><div><br></div><div>
printf("my pid: %d\n", getpid());</div>
<div><br></div><div> handle = dlopen("/lib/x86_64-linux-gnu/libm.so.6", RTLD_LAZY);</div><div> acos = dlsym(handle, "acos");</div><div><br></div><div> acos(0.5);</div><div> sleep(10);</div><div> acos(0.5);</div>
<div><br></div><div> return 0;</div><div>}</div><div><br></div><div style>I attach ltrace like this and get the following output:</div><div style><br></div><div style><div>joe@ubuntu:~/code/ltrace$ /tmp/test/usr/local/bin/ltrace -e* -p 2821</div>
<div>libm.so.6->(0x7fff07366f90, 0x7fff07366f90, 0, -1) = 0x7f0384fe06a0</div><div>libdl.so.2->__cxa_finalize(0x7f038582f078, 0, 0xffffffff, 0x7f038582ed50) = 0x7f0385627350</div>
<div>libm.so.6->(0x7f038526c0c0, 0, 0, 3) = 0x7f0385627350</div><div>+++ exited (status 0) +++</div><div><br></div><div style>It looks like the first line is ltrace tracing the call to acos but not matching the symbol name, for some reason?</div>
<div style><br></div><div style>If, instead I use -x, I see the symbol name:</div><div style><br></div><div style>joe@ubuntu:~/code/ltrace$ /tmp/test/usr/local/bin/ltrace -x acos -p 2840<br></div><div style><div>acos@libm.so.6(0x7fff313a7d10, 0x7fff313a7d10, 0, -1) = 0x7f56e25686a0</div>
<div>+++ exited (status 0) +++</div><div><br></div><div style>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.</div>
<div style><br></div><div style>Any idea why I might be seeing this? Do you see the same/similar output?</div><div style><br></div><div style>Thanks,</div><div style>Joe</div></div></div></div></div></div></div>