This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: uprobes-via-utrace notes
- From: Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Jim Keniston <jkenisto at us dot ibm dot com>, systemtap at sources dot redhat dot com
- Date: Fri, 4 Aug 2006 11:13:14 +0530
- Subject: Re: uprobes-via-utrace notes
- References: <1152812002.2845.11.camel@localhost.localdomain> <20060717081417.E1D77180063@magilla.sf.frob.com>
- Reply-to: ananth at in dot ibm dot com
On Mon, Jul 17, 2006 at 01:14:17AM -0700, Roland McGrath wrote:
>
> > When the breakpoint is hit, kprobes shows no interest, and do_trap()
> > handles it. utrace calls uprobes's report_signal callback with
> > action = SIGNAL_CORE and info.si_signo = SIGTRAP. (If there's a gdb
> > breakpoint there, it looks like action could be SIGNAL_IGN by the
> > time uprobes sees it. TBD)
>
> That's correct. The way that multiple engines interact is something of an
> unresolved area in utrace. As things stand, if ptrace was in the list
> first then it will get the callback first, tell the ptracer about it, and
> change the action to UTRACE_SIGNAL_IGN. A "noninvasive" tracing engine
> would want to be the one to go first, and hide the signal from other engines.
> There isn't currently any good way to control the order of the list.
How about adding a "priority" to be indicated at the time of
utrace_attach(), something akin to what we have with the kernel
"notifier" infrastructure?
All engines that don't have such a priority indicated can have a default
priority and all engines with the same priority can then be invoked in
registered order.
Ananth