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: Ingo Molnar <mingo at redhat dot com>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: 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 16:00:03 +0100
- 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>
On Tue, 2006-11-28 at 23:40 +0900, Masami Hiramatsu wrote:
> > If existing in-kernel debug info is not enough then i'd suggest to
> add
> > an extra build pass to the kernel to add it (dependent on
> > CONFIG_KPROBES) - a'la CONFIG_UNWIND_INFO. Am i missing something?
>
> As far as I know, there is no debuginfo in the kernel which is
> loaded in the memory. But the debuginfo is included in the
> "vmlinux" file (not the "vmlinuz" file).
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. The info that is needed
here is a table of all valid instruction boundaries, correct?
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?
Ingo