This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion at Linux Foundation Japan Symposium


On Sat, Dec 20, 2008 at 07:38:31PM -0500, Frank Ch. Eigler wrote:
> 
> Some of this has been predicated on the belief that debuginfo quality
> will improve enough that we do not need to resort to hard-coded
> per-architecture per-compiler hacks like some in gdb.

Yes, but how long will people need to wait before debuginfo quality
will improve?  And when such a hypothetical improved compiler be
available and trusted to compile the kernel correctly?  (And how much
slower will it be compared to current versions of gcc's?   :-)

More importantly, what will systemtap development do in the meantime?
There are a couple of choices:

1) Do nothing.  Kernel developers will continue to largely give up on
Systemtap, mostly out of frustration.  Frustration that their needs
aren't being met; frustration that suggestions that they make are
blown off as not being important, or concerns that are in the
minority, or whatever.  The process of getting userspace probes in
will go slowly (if at all).  I haven't seen a new version of the
patches submitted in months --- and the 2.6.29 merge window will be
opening soon.  Whoever is managing getting the necessary userspace
probe patches into mainline seems to be totally ignorant about
mainline processes --- why hasn't a "this is what we intend to merge"
been sent to LKML already?   

2) Explain to developers how to use Systemtap in a painless way as
possible.  This means no modules, since debuginfo is a disaster with
modules (so helping people create configurations that don't use
modules would be helpful); and/or with a focus on markers as a
debugging mechanism, even if that means that you have to recompile the
kernel first before they can be used.  If making markers more helpful
is the goal, then work to make the Modules.marker file consistently
installed in the same place, or to make Systemtap look to find it in
multiple places, is going to be important.

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.  

In fact, given the utterly worthless (and vastly huge) debuginfo, the
only advantage SystemTap has over ftrace is (a) Systemtap has access
to the function parameters, and (b) Systemtap allows you to filter
logging information based on conditions, which is more efficient than
filtering in userspace.  Being able to probe individual lines usually
doesn't work, so most of the time what I find is the only thing I can
count on is add a tap at the beginning and end of the function ---
which I can do using ftrace.

> > [...] Would could build some scripts with the binaries where debug
> > info is available, interpret that info as relative offsets to public
> > symbols then dispense with the info on the shipped production
> > script.  See where I'm going here?
> 
> It sounds like an interesting sort of shortcut - one that we have not
> seriously considered.  It may be far too optimistic, considering the
> degree of configuration/optimization change possible between two
> similar kernel builds, and the prevalent hostility toward reusable
> kernel modules.

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.

						- Ted


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]