Re: kernel summit session on systemtap

[Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>]

On Thu, Sep 18, 2008 at 11:46:29AM -0400, Theodore Tso wrote:
> On Thu, Sep 18, 2008 at 09:00:15AM +0100, R. J. Moore wrote:
> > I don't know whether it is possible with the latest code, but for  
> > debugging purposes, I would be happy if SystemTap could operate on  
> > external names and relative addresses - i.e. without the need to have  
> > any symbolic information. 
> 
> You can certainly set tracepoints that way.  I don't know how easy it
> would be to fetch out register information or interpret complex data
> structures living on the stack or in function parameters without debug
> information, though.  Usually if I have to do that level of analysis,
> at least at this point it's faster for me to rebuild without debuginfo
> information, drop the use of system tap, and retreat to printk
> debugging.

Or you could use just vanilla kprobes. Kprobes allows for users to specify
a symbol name string (kp.symbol_name) and an offset (kp.offset) and the
probe is inserted at that exact location. No printks and no requirement for
debuginfo :-)

...
 
> (By the way, is testing to make sure all
> of the tapsets in the tree to make sure they work still turned off
> because so many of them are still broken?  That was few months ago
> when someone on the list told me that, but that was another face-palm
> moment for me.)   

There are some probe points in tapsets (eg., the signal tapset) which
used certain function probes, which later got inlined due to compiler
optimizations. Such tests do fail.

A panacea for such cases is to migrate to a kernel marker based mechanism.

Ananth