This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: external systemtap meeting notes 20070816
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Jim Keniston <jkenisto at us dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com, utrace-devel at redhat dot com
- Date: Tue, 04 Sep 2007 21:49:32 -0400
- Subject: Re: external systemtap meeting notes 20070816
- References: <mailman.8592.1187789486.29635.external-perftools-list@redhat.com> <y0mlkc3k23c.fsf@ton.toronto.redhat.com> <mailman.3771.1188945116.11517.external-perftools-list@redhat.com>
jkenisto wrote [untrimmed for forwarding to utrace-devel]:
> [...]
> Uprobes maintains one utrace engine per probed task. When
> instrumentation modules A and B register uprobes at the same address,
> and that probepoint gets hit, uprobes's signal (SIGTRAP) callback gets
> called (once). It calls both A's and B's handlers (a la aggregate
> kprobes), then eats the SIGTRAP.
>
> If A and B each got its own engine, then what would uprobes's callback
> do? If the callback eats the SIGTRAP, then the 2nd handler never gets
> called. If it doesn't eat the SIGTRAP, the probed process takes the
> SIGTRAP and dies. We could work up some new way that A and B could
> coordinate this sort of thing, but then we're back to needing some sort
> of shared (among instrumentation modules) data structures. And what we
> have now works just fine.
This is probably related to Roland's "engine interaction" note
(http://tinyurl.com/22jt2o). It would be nice if concurrent engines
could nest transparently - or failing that, at least be aware of each
other enough to get this right.
- FChE