Re: SystemTap Translator Questions

[fche at redhat dot com (Frank Ch. Eigler)]

kevinrs wrote:

> I am familiarizing myself with latest SystemTap snapshot on FC4 and
> have some questions about probe scripts I hope can be clarified.

Sure.  It's great that you got that far.


> 1. This short script fails to compile.
> [...]
>     finding location for local 'fd' near address 0xc016c591, module bias 0x0
>     finding location for local 'buf' near address 0xc016c591, module
> bias 0x0
>     finding location for local 'count' near address 0xc016c591, module
> bias 0x0
>     ./stap: cannot get byte_size attribute for type size_t: no error

This is probably a dwarf data or elfutils processing problem that we
may be able to work around in the translator.  I'll create another
test case and open a bug against it.

> When I comment out the references to $count in the probe alias I can
> compile, however there is no output until I also comment the reference
> to $buf.

I wonder if this may be related to the embedded-C calls to
_stp_printf/flush.


> 2. ./stap testsuite/buildok/five.stp causes my system to hang,
> resulting in a force-shutdown/reboot.
>      #! stap -p4
>     probe kernel.function("schedule") { log ("arrival") }
>     probe kernel.function("schedule").return { log ("departure") }

The .return probes were broken until about yesterday's CVS commits.
If you look at the generated C code, you should see the kprobes and
kretprobes addresses slightly differ (one past the prologue, the other
right at the beginning of the function).

It may turn out that the "schedule" function cannot be safely probed
in this way.  We may need to collect a blacklist and/or whitelist.
Try it with some other, vanilla, less context-switchy function, after
you've refreshed your stap build.


> [...]
> 3. ./stap testsuite/buildok/six.stp does not compile:
> [...]
> Is this happening because "context_switch" is inlined?

Yes.  Bugzilla #1155 covers this.


> 4. ./stap testsuite/semok/seventeen.stp does not compile because it
> fails to resolve $nr_segs.
> [...]
> The comment '# $nr_segs is not an lvalue here' indicates that script
> should fail to compile. 

Not really - that was just related to the (now fixed) bug #1183.
I'll extend the comment.

> What I don't understand is why the translator cannot resolve
> nr_segs, which is a parameter to pipe_writev.

It's another dwarf data or elfutils processing problem, I expect.
I'll open a bug against this.  Also, feel free to open bugs in
bugzilla yourself.


- FChE