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: James Bottomley <James dot Bottomley at HansenPartnership dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Peter Zijlstra <peterz at infradead dot org>, Andi Kleen <andi at firstfloor dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, systemtap at sourceware dot org, jbeulich at novell dot com
- Date: Fri, 18 Jul 2008 08:21:24 -0500
- Subject: Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1216387286; bh=sBXBQ4R7/Mkb7rt9lwvXhU+9sc/I0T+kk7oGm1o7Qr Y=; l=1577; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=o1iTUxDJW/A+gPP8NWnl6x92B161Hv6MJ5Cuc xPd3wSj7haSeUIlYjjn5SBf7BOYgmc9xebpDVfkbA4ok7K3gUiQ3pjq6lkgv2xNlcGl VGBNQMKMskAVB23wr8rYxbxe1LDwR4CZ+IzXTPC9kbWj7zsndR3IAjAW+8ZARhNjXKU =
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1216387285; bh=sBXBQ4R7/Mkb7rt9lwvXhU+9sc/I0T+kk7oGm1o7Qr Y=; l=1577; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=GpKKclrzoZhochETcTpMIILM98+ddWdjqPTwP LMxB0RxmSln5oW2r3p43MkpNCCRKg4uRaBzoz3o0EvsVfBOtsyQ6TGrdsLv2C9/gkPd In/omTG7uDshQZb6ouSr6M4LHT2Iyyli/e4Lk5uIaq4dGTA1Z4fAXBLha53lWaDgn8I =
- 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'm not entirely convinced systemtap wants full stack unwinding in the
kernel. What the kernel wants is the call trace, which it can do with
kallsyms. However, systemtap in userspace sees all the relevant dwarf
information as well ... it could do a much better job of unwinding: give
file and line and arguments for function calls, for instance. All it
really needs is to have the relevant pieces of the stack relayed back.
James