Re: How to debug what I am doing wrong?

[Theodore Tso <tytso at mit dot edu>]

On Thu, Jul 17, 2008 at 07:00:12PM -0400, Frank Ch. Eigler wrote:
> Theodore Tso <tytso@mit.edu> writes:
> 
> > [...]
> > Unfortunately, I then get a different error message:
> >
> > % stap ext4-check-desk.stp
> > semantic error: failed to retrieve location attribute for local 'sb' (dieoffset: 0x9cf22): identifier '$sb' at ext4-check-desk.stp:3:47
> > [...]
> > Sb is a parameter passed into ext4_check_descriptors, so don't know
> > what it's issuing *this* complaint:
> >
> > static int ext4_check_descriptors(struct super_block *sb)
> > {
> > 	struct ext4_sb_info *sbi = EXT4_SB(sb);
> 
> This is one of the cases where gcc's dwarf debugging data is
> incomplete.  See http://gcc.gnu.org/PR23551 and
> http://sources.redhat.com/PR1155, and many discussions on gcc-patches
> and elsewhere.  While it will get better (RH and others are investing
> serious effort in it), it may never be complete enough.

So is this a good summary?  With a sufficiently modern gcc (presumably
all 4.x compilers), if there is a static function which is only used
once, it will almost certainly be not be compiled into a separate
function, but incorporated into ths calling function --- and then
optimizations involving function parameter folding kicks in, and at
least given the DWARF information ommitted by a recent gcc, any
attempt at accessing variables in a static inline function has a very
high likelihood of being Doomed To Fail.

> 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.

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, since depending on the compiler used and
optimizations, the necessary DWARF information may not be available.
Also, static functions probably have a higher probabilty of changing
over time, making the tapset much less reliable.

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?

Regards,

						- Ted