Re: How to debug what I am doing wrong?

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

On Fri, Jul 18, 2008 at 07:50:15AM -0400, Theodore Tso wrote:

> [...]  So is this a good summary?  [...]

Yes.

> > You may be able to work around this by using .statement() probes,
> > placing one near the call site of this function, hoping to extract the
> > same pointer.
> 
> I tried multiple .statement probes inside the function, and that
> didn't work.  Statement probes around the call site of function didn't
> work either.  I ultimtaely managed to grab it by grabbing using
> .module().function() of the calling function, and grabbing from the
> parameter there.

OK.  I'll write a wiki tip page about this issue.

> This may already be documented somewhere, but basically it sounds
> like it is a very Bad Idea for tapsets to try to grab information
> from inside static functions [...]

Yeah, it is difficult to make work reliably.

> It sounds like a good regression check would be to make sure all of
> probe points in the tapsets can reference all of the desired
> variables given a kernel build tree and debuginfo files.  Is this
> already being done, or is there an easy way to do this?

There are two facilities: disabling systemtap-side script
optimizations with "-u", so that any $expressions that are not used by
an end-user (or test-suite) script are nevertheless accessed - sort of
as if they were "volatile".  At this point, our test suite does not
blanket-use this, because of the dramatic number of failures (though
it's not clear to what extent the problems are due to debuginfo or
actual tapset bugs).  Soon also we'll have a way of referring to
pretty-printing of all variables in scope ($$vars).

- FChE