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: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Ingo Molnar <mingo at redhat dot com>
- Cc: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Satoshi Oshima <soshima at redhat dot com>, "Frank Ch. Eigler" <fche at redhat 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>, 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: Tue, 28 Nov 2006 10:56:22 -0500
- Subject: Re: [RFC][PATCH 0/4][kprobe](djprobe) Direct jump optimized kprobes
- References: <4562A150.2030606@hitachi.com> <1164632388.22536.109.camel@earth> <y0my7pwplqf.fsf@ton.toronto.redhat.com> <456B7D4B.4050202@redhat.com> <1164710436.25787.31.camel@earth> <456C4A5D.8020301@hitachi.com> <1164726004.25787.56.camel@earth>
Hi -
On Tue, Nov 28, 2006 at 04:00:03PM +0100, Ingo Molnar wrote:
> [...] correct, that sort of debug info is not included in the
> kernel image - but some of it could be included - just like unwind
> info, or kallsyms and other info is included currently. Whatever can
> be extracted at build time we can also insert into the kernel image.
That's true, but the total possibly needed information is huge.
> The info that is needed here is a table of all valid instruction
> boundaries, correct?
It's not clear that this is sufficient. Statement boundaries (to the
extent they still exist in object code) may be the thing.
> OTOH, userspace (SystemTap) has all this information handy already,
> because it already has to parse the -g debuginfo - hence it's more
> natural to delegate this there?
Yes, probably. While this maintains the possibility that if the
user-space screws up badly enough, the kernel dies, this is nothing new.
- FChE