This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][PATCH 0/4][kprobe](djprobe) Direct jump optimized kprobes
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Ingo Molnar <mingo at redhat dot com>
- Cc: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, SystemTAP <systemtap at sources dot redhat dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Prasanna S Panchamukhi <prasanna at in dot ibm dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Jim Keniston <jkenisto at us dot ibm dot com>, Martin Bligh <mbligh at google dot com>, Greg Kroah-Hartman <gregkh at suse dot de>
- Date: 27 Nov 2006 17:29:12 -0500
- Subject: Re: [RFC][PATCH 0/4][kprobe](djprobe) Direct jump optimized kprobes
- References: <4562A150.2030606@hitachi.com> <1164632388.22536.109.camel@earth>
mingo wrote:
> [...] I'm wondering whether it could be made a 100% transparent
> speedup to kprobes: how hard would it be to do a simplified
> disassembly of the target address to automate the 'this kprobe can
> safely be turned into a djprobe transparently' step [...]
The entire criterion is not easy to check at the binary point. In
particular, it is hard to tell whether some part of the overlaid
instruction sequence is the possible target of a branch elsewhere.
> Userspace would have to do something like this anyway (unless i'm
> missing something), correct? [...]
Yes, but debug- or symbol-consuming userspace would have more
information to judge from.
- FChE