Re: SystemTap

Re: SystemTap

[Frank Ch. Eigler]

Hi -

> OK as soon as it works nicely i will add [ubuntu kernel rebuild
> instructions] to the wiki.

Great.

> I am trying out the samples, with one i have troubles, can you run
> inodewatch-simple.stp ?

Not quite; the old scripts transcribed into the documentation fell
behind modern kernels.  $file->f_dentry would need to be replaced with
$file->f_path->dentry.  The tapset library of script fragments is
meant to hide such changes (see tapset/vfs.stp for example), but that
script must have been written with an older version of the tapset in
mind.  With current tapset actually, you'd replace those two whole
$-expressions with:
   dev_nr = dev
   ino_nr = ino
since vfs.read/.write provide "cooked" dev & ino values.

See $prefix/share/doc/systemtap*/examples for more current samples.

- FChE

systemtap

[王秋从]

[-- Attachment #1: PanCBbA0MEv.rgh --]
[-- Type: application/octet-stream, Size: 47459 bytes --]

Re: Systemtap

[Vara Prasad]

Benjamin Thery wrote:

> [..]
> I'm trying to use Systemtap to trace some network events in order to 
> find a bug. I have a very basic knowledge of stap and there is a 
> couple of points I'd like to clarify:

Thanks for using SystemTap and we will try our best to help you.

>
> Placing a probe at the beginning of a given function always work, but 
> when I try to set the probe on the return statement of a function it 
> sometime fails. Stap says the probe can't be set.

Just to be sure i understand correctly, you are putting probes on a 
return statement to find when the function is returning, is it possible 
you could use return probes for the same. Return probe guarantees you 
will be able to run the handler at the time function returns no matter 
which of the return paths it takes as long as it is not an inline function.

Coming to not able to set probes on a return statement it could be 
related to compiler optimization. Was the function you are trying to do 
an inline function?

> I also have a problem when I try to set a probe at a given line in a 
> source file: sometimes it seems the probe isn't where I supposed it 
> is. For example, I tried to test if the code executed enters a 
> particular if-statement: stap trace never displayed my probe, whereas 
> I had a printk() trace that suggested the opposite).

It could be related to compiler optimization.

>
> Are these problems possibly due to the kernel being compiled with -O2 
> flag? Is it a side effect of optimization (similarly to debugging an 
> optimized program with gdb)?
>
It could be.  We know of  cases where we are not able to place probes in 
the middle of functions due to compiler optimizations hence we are 
pursuing static markers to address this issue.

> I'm wondering if it is advised to compile the kernel without 
> optimizations to be able to set probes wherever we want.
>
Certainly worth a try.

> Thanks for your help.
>
> Regards,
> Benjamin
>
   
Please let us know your results after trying without optimization.

bye,
Vara Prasad