This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/11249] Tracking executable plus library fails on i386
- From: "jkenisto at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 5 Mar 2010 17:39:42 -0000
- Subject: [Bug runtime/11249] Tracking executable plus library fails on i386
- References: <20100204125941.11249.mjw@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jkenisto at us dot ibm dot com 2010-03-05 17:39 -------
(In reply to comment #5)
...
>
> I haven't explicitly tested uprobes on relative calls and jumps, so maybe
> they've never worked. Perhaps all the calls and [conditional] jumps listed in
> Comment #4 of PR #5509 are suspect.
Come to think of it, a couple of years ago I ran tests where I put a uprobe on
every instruction in a specified function or address range. (They took
advantage of the fact that for x86_32, the address in the objdump -d output was
the virtual address in the running process.) They worked only when stap supported
probe process(pid).statement(addr).absolute[.return]
which it didn't for many months after dwarf support was added. I'll attach the
awk scripts that generated the stap scripts.
Anyway, those tests definitely probed some relative jumps and calls -- but not
in libraries. It might be worthwhile to try them again. (Srikar and/or Ananth
are picking this up investigation again.)
Is it possible you're seeing a situation where the destination address, when the
call/jump instruction is in the SSOL area, is past 0xc0000000?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11249
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.