This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: kernel summit session on systemtap
Hi, Ted -
On Thu, Sep 18, 2008 at 11:18:43AM -0400, Theodore Tso wrote:
> [...]
> > - improving quality (benefits) of dwarf
> > - shrinking dwarf dramatically
> > - if all else fails, dwarf subsetting
>
> What do you think is the timeline for this happening? I assume this
> requires changes to gcc, right? So would an estimate of 6-9 months,
> minimum, be a fair one [...]
For improving debuginfo quality, yeah. For subsetting or compressing,
we can probably attack the problem with separate postprocessing tools
that could be ready sooner.
> "make install" to strip out the debuginfo so that the partition
> containing /lib wouldn't run out of space. Right now I manually
> install the full set of module files in /usr/lib/debug/lib/modules/... via:
>
> make INSTALL_MOD_STRIP=1 install_modules
> make INSTALL_MOD_PATH=/usr/lib/debug install_modules
That's a clever alternative to using the separate-debuginfo style
stripping.
> > (By the way, do you build distro-style kernels on your laptop, with
> > allmodconfig or somesuch, or something more linus-sized?)
>
> I do both. The distro-style kernels are the ones that I build with
> debuginfo information, and it's been useful for playing around with
> systemtap, but the moment I need do any serious development work, I
> tend to fall back to a limited subset of compile options, generally
> without any modules, and printk debugging.
OK; is there some obstruction in the way of using systemtap on your
'serious development' kernels?
> Once we get a useful circular buffer, I'd probably start logging to
> the circular buffer and use grep as the alternative to systemtap or
> printk debugging.
OK.
> As a result, I've had no motivation to create any tapsets, since at
> least for my own personal needs, the costs of creating the debuginfo
> so that SystemTap would be useful for my personal needs just far
> outweighs the benefits.
My recollection of the ksummit yak was that the sort of tapset that
kernel people would be willing to help write/maintain consisted of
compiled-in instrumentation like markers, or whatever event layer
comes on top of the new ringbuffer widget. If that's done right, it
should not require debuginfo for systemtap to hook in.
> > Your information is slightly obsolete. We just added some such
> > automation, and can do more.
>
> Glad to hear it. I suspect then that this page:
> http://sources.redhat.com/systemtap/wiki/SystemtapDtraceComparison
> is also slightly out of date.
Yeah.
- FChE