This is the mail archive of the
mailing list for the systemtap project.
Utrace usage queries
- From: Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>, Jim Keniston <jkenisto at us dot ibm dot com>
- Date: Fri, 8 Sep 2006 09:43:28 +0530
- Subject: Utrace usage queries
- Reply-to: ananth at in dot ibm dot com
As we try to understand utrace and exploit it for userspace probing, a
couple of questions cropped up:
1. Is there a specific mechanism you had in mind to insert a breakpoint
at a userspace virtual address?
This is our current understanding:
- A request to register a breakpoint at a virtual address will first
register a engine with a set of report callbacks and sets the QUIESCE
flag, and waits for the callback.
- Once the callback happens, the breakpoint is set at the virtual
address requested (via, say, access_process_vm()).
Is the approach right? Do you have better suggestions? This is important
in the sense that a request to register a breakpoint at a userspace
address will ideally have to block till the breakpoint is in place, ie.,
the registration "event" is complete only _after_ the QUIESCE callback
completes inserting the breakpoint.
2. What is the preferred mechanism to return errors from report_*
callbacks? Eg., say, a genregs_set failed when in a report_signal callback.
AFAICS, the report callbacks return the new utrace engine state bitmask.