Re: wiki page on using stap without dwarf

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Mon, 2008-05-19 at 22:04 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Mon, May 19, 2008 at 04:35:39PM -0700, Jim Keniston wrote:
> > > Thanks.  One question re. usage: when would one want to use the
> > > "--kelf" option?
> > 
> > --kelf has the following implications:
> > 1. It affects whether/how we report the absence of dwarf info.
> > 2. It brings into consideration functions that are in the symbol table
> > but not the dwarf info -- typically assembly-language functions.
> 
> That doesn't seem to answer the question in a way that a systemtap
> user would understand.  When should they use --kelf?

They should use --kelf when
1) they have a vmlinux file but no dwarf for it; or
2) they have a vmlinux file (with or without dwarf) and they want to
probe assembly-language functions by name.

There's more detail about this in the stap(1) man page than in the wiki
article.

> 
> 
> > [...]  That said, your suggestion of ~1 month ago -- that we consult
> > the dwarf only if the elf doesn't provide what we need, and thereby
> > save some cycles in stap -- has merit.  I'll open an enhancement
> > request for that, unless you've changed your mind about it.
> 
> It still sounds like it should be a win.  (One problem - shared by all
> the symbol-table sources - is relocatability, since we lose section
> information.  Likewise, we lose section-based blacklisting, hmm...)

Section-based blacklisting works for --kelf, and can probably be made to
work for --kmap, per Roland's email.  As far as I know, relocatability
is not a problem -- at least if you're using elfutils 0.131 or later.

> 
> > My hunch is that we'll save a lot MORE cycles if we bail out of
> > dwfl_linux_kernel_report_offline() as soon as we've "reported" all the
> > modules we're probing (typically just the kernel).  
> 
> I believe we are mostly doing that now (git grep DWARF_CB_ABORT).

We short-circuit the query_module() business, which is good, but by then
we've already done way too much work.  On my 1.5-GHz system with 500+
modules in /lib/modules/`uname -r`, it takes over 15 seconds to run
dwfl_linux_kernel_report_offline() with a cold cache.  It's much, much
faster on subsequent runs, but that's not the kind of performance we
want users to see the first time they run stap.  If I short-circuit
dwfl_linux_kernel_report_offline() after it reports the kernel, it's
about 1.5 seconds on a cold cache.

So if we could keep track in phase 1 (say) of which modules we're
actually probing, and check them off as they get reported to us by
dwfl_linux_kernel_report_offline(), and stop when we have them all, we
could save a lot of time.

> 
> > I thought I saw a PR about that, but I can't find it at the moment.
>  
> There is bug# 3498 that could help scripts that use some small set of
> modules.

It's a terse PR, but yeah, it seems to refer to the above problem.

> 
> - FChE

Jim