This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: thoughts about exception-handling requirements for kprobes
richardj_moore wrote:
> I've been thinking about the need for exception-handling [...]
> Cases 1 & 4
> The expected exceptions in user pre- and post-handlers are easy to deal
> with in a way that performs well: this is via a setjmp/longjmp mechanism.
> [...]
Right.
> It would seem better to have kprobes put a wrapper around setjmp
> (ksetjmp) and issue the longjmp directly. kprobes could also
> maintain a maxfault counter for the probe so that we can exit
> recursive fault situations.
Sure. Perhaps the "kprobe" struct could get a jmpbuf field that could
be initialized using a call from within the pre/post handler. The
default kprobes fault handler could check whether this field was set,
and if so, just longjmp to it.
> [...] Could we exploit if from systemtap?
Certainly - the standard probe prologue/epilogue could hook into it
just inside the lock/unlock sequence. Given the data in the context
(such as last_stmt), it could synthesize an error message to at least
place blame at the right source-level point.
> How about using a try-catch semantic [...]
If necessary, some nested structure like that could be put also into
the scripting language. But if all we want is general crash
protection, then the single implicit try/catch around the entire
handler block may well be enough.
- FChE