This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)
- From: Peter Zijlstra <peterz at infradead dot org>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, James Bottomley <James dot Bottomley at HansenPartnership dot com>, linux-kernel <linux-kernel at vger dot kernel dot org>, systemtap at sourceware dot org, jbeulich at novell dot com, arjan <arjan at infradead dot org>, sandmann at daimi dot au dot dk, Ingo Molnar <mingo at elte dot hu>
- Date: Fri, 18 Jul 2008 15:10:27 +0200
- Subject: Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)
- References: <1216146802.3312.95.camel@localhost.localdomain> <87ej5rsgk4.fsf@basil.nowhere.org> <1216373009.5232.130.camel@twins> <y0m7ibjjqg4.fsf@ton.toronto.redhat.com>
On Fri, 2008-07-18 at 09:02 -0400, Frank Ch. Eigler wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > [...]
> >> Right now x86 doesn't really have a good reliable unwinder that
> >> works without frame pointer. I think systemtap
> >> recently switched to Jan Beulich's dwarf2 unwinder. Before
> >> switching to the in kernel unwinder that one would need to be
> >> re-merged again.
> >
> > Those are two separate issues.
> >
> > 1) stap ought to use the kernel's infrastructure and not re-implement
> > its own.
> > 2) if the kernel's infrastructure doesn't meet requirements, improve
> > it.
>
> They are related to the extent that readers may not realize some
> implications of systemtap being/becoming a *kernel-resident* but not
> *kernel-focused* tool.
>
> For example, we're about to do unwinding/stack-traces of userspace
> programs. To what extent do you think the kernel unwinder (should one
> reappear in git) would welcome patches that provide zero benefit to
> the kernel, but only enable a peculiar (nonintrusive) sort of
> unwinding we would need for complex userspace stacks?
I think sysprof (kernel/trace/trace_sysprof.c) already does user-space
stack unwinding. So pushing that capability further up the chain when a
second user (stap) comes along makes perfect sense.