This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Discussion at Linux Foundation Japan Symposium
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: Theodore Tso <tytso at MIT dot EDU>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sources dot redhat dot com
- Date: Mon, 22 Dec 2008 17:40:48 -0500
- Subject: Re: Discussion at Linux Foundation Japan Symposium
- References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu>
Hi Ted,
Theodore Tso wrote:
> 3) Actually try to find a way for Systemtap to be more useful
> *without* waiting for Godot^H^H^H^H^H^H some hypothetical future,
> probably at least 18-24 months away, when new gcc and toolchain
> becomes available that will magically and mystically Solve All
> Problems. Consider how ftrace works; it very cleverly uses/abuses the
> profiling hook inserted gcc -pg. Note that it doesn't wait for magic
> new capabilities in the toolchain.
Actually, I'd like to find a way (or a bridge of the gap amoung us)
to solve this problem positively...
Hm, what issues are making systemtap useless?
- Using debuginfo
Pros.
- with debuginfo, systemtap can access local variables and
query members of data structures by name.
- debuginfo also enables line-by-line tracing(need to be improved),
userspace probing, and so on.
- kernel developers can build its debuginfo by themselves.
Cons.
- debuginfo is too huge to distribute all developers and users.
- debuginfo is too huge and complex so that it increases compilation
time and disk space consumption.
- most of developers may not need line-by-line tracing(and it
might not work in some cases). they just want to trace function
boundary (maybe, with parameters).
- Module-base
Pros.
- Systemtap allows you to filter logging information based on conditions.
- no-module configuration is not popular...
Cons.
- some people build kernel with no-module configuration.
- Non upstream first
Pros.
- systemtap is just a tool.
- systemtap can catch up with upstream in several days after releasing.
Cons.
- systemtap works as a tool, but it strongly depends on the kernel.
if upstream kernel is updated, systemtap will be broken.
- because of waiting for systemtap update, kernel developers can't
use systemtap on the development kernel.
- maintenance cost will increase, especially on runtime and tapset.
- utrace and uprobe are a part of kernel, but no patch was posted
these months.
Are these items right? (I think some items should be updated.)
> Another solution which I've suggested in the past, but which has been
> utterly ignored, (since, after all, what does a Kernel Developer
> know?) is to simply generate the debuginfo information on demand so
> the function parameters on entry can be decoded. We have the header
> files after all, so it shouldn't be hard to generate a pseudo function:
>
> extern int foo_kernel_function(struct file *f, off_t offset, size_t len,
> void *ptr)
> {
> return 0;
> }
>
> ... and then use that to generate the debuginfo information for that
> information so Systemtap knows how to decode the function parameters
> on entry. This would be enough such that Systemtap can probe any
> public function in System.map --- and obtain the function parameters
> for any function which is present in the kernel headers --- all
> without requiring users to download or create hundreds of megabytes of
> largely useless (on a value-per-megabyte-basis) !@#!@# debuginfo
> information.
Good idea! It seems much easier than introducing new CTF-like compressed
debuginfo... why did anyone ignore...?
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com