This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: 02-16-2006 meeting minutes
> [...]
> Frank wanted kprobes to have three states -
> 1) no kprobe.
> 2) kprobes registered, but not running
> 3) kprobes is running.
More precisely, I meant that if the various hooks kprobes has in the
kernel could differentiate between these three cases, more
optimization opportunities may show up. For example, it would be
desirable to avoid any kprobes-related overhead for a system in state 1.
> [...]
> Frank suggested that kprobes fault handler should do more of the general
> cases too instead of just pagefault case as it does now.
> [...]
To clarify, I suggested that the kprobes fault handling logic should
eventually make it possible to catch all of these occurring in a
pre-handler:
- The current user- and kernel-side pointer dereference macros that
contain exception fixup tables.
- Other page faults that may originate from systemtap code *without*
fixup tables, such as embedded-C.
- Faults other than page faults.
Ideally, all these should be able to do a setjmp/longjmp inspired
return into the pre-handler, where systemtap-generated code can
signal an error and clean up.
- FChE