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



systemtap-owner@sourceware.org wrote on 19/12/2008 19:53:35:

> [image removed]
>
> Re: Discussion at Linux Foundation Japan Symposium
>
> William Cohen
>
> to:
>
> Frank Ch. Eigler
>
> 19/12/2008 19:54
>
> Sent by:
>
> systemtap-owner@sourceware.org
>
> Cc:
>
> KOSAKI Motohiro, Satoshi OSHIMA, systemtap, mhiramat,
> hisashi.hashimoto.wh, Yumiko SUGITA
>
> Frank Ch. Eigler wrote:
> > Hi -
> >
> > On Fri, Dec 19, 2008 at 08:58:58AM +0900, KOSAKI Motohiro wrote:
> >>>> Systemtap always requires kernel debuginfo to use.  Unfortunately,
> >>>> it is hard for users of some distributions to have debuginfo.
> >>> Those distributions ought to be lobbied to improve this situation,
> >>> since there are many non-systemtap uses of debugging data - such as
> >>> debuggers, kernel- and user-space crash dump analysis tools.
> >> [...]
> >> In enterprise usage, crash dump analysis is provided by vendor.
> >> but tapset run on customer. [...]
> >
> > That is just one scenario.  Another compelling use for debuginfo is a
> > tool like oprofile.
> >
> > - FChE
>
> For the case where oprofile data is being mapped back to lines in the
source
> code debuginfo is needed. However, for the case just want to know which
> functions the code is spending time in oprofile doesn't use debugging
> information produced by -g; it just looks for the function locations in
the
> code.  Unfortunately, the strip operations used for binaries in
distribution
> strip out all information from the binary leaving just the minimal
executable
> bits, making the debuginfo the only place to get that information.
>
> It would be nice if there was something between the extremes of a
> huge amount of
> information in the debuginfo or nothing at all.
>
>
> -Will

I attempted to reply to this earlier but it never made the mailing list,
apologies for repeating myself to those who did read my earlier response.:

My suggestion and hope is that we can weakening the dependency between
SystemTap
and debuginfo. On taking a look back to the antecedents to kprobes i.e
dprobes
and before that dtrace for OS/2 we didn't rely explicitly on debuginfo.

Both dprobes and dtrace would use the debuginfo if available but would also
work
with public symbols in the module header and with expressions based on
these
symbols.

Is this useable? Yes it is:

for one-off debugging scenarios I often used a crashdump to begin the
anbalysis
and would follow up with a probe based on what I say in the dump. It's
relatively easy, when dealing with the binary data to develop probe
expressions
based on offsets to public symbols. This would be useful but would require
System
Tap to change.

For performance investigation and regular tracing, the probes can generally
be
developed in advance of their need. What we did with OS/2 was to build
probe
binaries based on debuginfo as part of the module build. Once the binary
was build
there was no need for debuginfo to be present to execute the probe. So we
stripped
the debuginfo from the module and shipped the stripped module along with
its
probe binary.

We could do something similar with SystemTap especially for the pre-built
probe
libraries. Debug info is only really needed when developing probes without
access
to a dump. I think a lot of mileage could be gained from System Tap by
having
pre-built probe modules that matched a given distro service pack or kernel
build.
We wouldn't need to change System Tap to support this. We could then
concentrate
on providing a host of useful pre-built probe modules.

Richard M.




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