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 00:41:04 -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 00:41 -------
The general protection fault on the call suggests that the destination address
of the call is bad. (I think the IP is left at the faulting instruction.) The
destination is computed by adding the displacement in the call instruction to
the address of the next instruction. If you're in a big vma (e.g.,
libc-x.x.so), that displacement can be big. If you move the call instruction to
the (1-page) SSOL area, that big displacement can take you out of the SSOL vma,
to a potentially unmapped address. Does that warrant a GP fault? Uprobes
adjusts the IP after the call, so it's back in the probed vma, but by then it
may be too late.
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. (If that turns out to be the case, I have
an idea of how to support these instructions correctly.)
This hypothesis doesn't explain why Srikar doesn't see the problem in
utrace-gdbstub-uprobes.
--
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.