Re: Sample tapset source file

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

Hi -


On Mon, Apr 18, 2005 at 04:25:24PM -0700, Jim Keniston wrote:
> In an effort to inject some new perspective into the tapset discussion,
> I hereby enclose what I claim to be a complete, non-trivial tapset
> source file. [...]

Thanks for giving this a try.

> [...]
> ENHANCEMENTS / NEW IDEAS
> 1. A tapset source file may contain C code set off by %{ and %} lines.  [...]
> The systemtap compiler compiles a copy of this C code with cc ???c ???g3 so
> it can find the necessary macro, function, and struct declarations
> without having to parse the C code.

This idea will require a lot more motivation.  Your sample C functions
dereference, in an unsafe way, a given pointer that is somehow
supposed to be "guaranteed" a valid filp.  But if a user script can
call these functions, then this cannot be assumed.

Plus your sample functions already have a proposed syntactic
alternative for safe dereferencing of target-space data (the
$var->field idea).  Why not choose a different example?

For what it's worth, I continue to be ambivalent about the wisdom of
allowing any embedding of C into script, whereas you're clearly
gung-ho on this.  It would be easier to sway the group one way or
another if the examples presented were inexpressible any other way.


> [...]
> 3. Probepoint export specifications define which named values are
> exported to client handler functions.

You're in effect introducing the concept of a probe handler wrapper
here.  This idea is interesting; let's give it a little while to
ripen.

> 4. Probepoints can be named using the probename("<name>") clause. 
> References to this probepoint can use the name instead of
> the entire probepoint specification.

Aliasing is probably useful, but the dotted syntax won't work because
it appears to be whitespace-sensitive.

> 5. Handlers can be named using the handler("<name>") clause.
> 6. Certain handler names -- e.g., "trace" -- have special meanings.

You will need to provide more motivation and examples for the use of
this new "handler naming" construct.

> 7. A probepoint specification can include a context("<sourceline>")
> clause, so that the probepoint stays on the right source
> line even when the line number changes.

Yes, we have talked about this before.  Note that this method will
only be usable if actual source code (not just debugging data) is
available.

> [...]
> 	- $probee -- defined in any handler the corresponds to a probepoint in
> a function (or upon entry to or return from a function); evaluates to
> the function's name.

One might define this as a reverse mapping from PC address to nearest
symbol name.  But consider inline functions and event-based rather
than kprobes-based probes, where the probe point specification
identifies a non-specific "probee".  What do you think a script user
would want to see, as distinct from the actual probe point
specification triggering the handler?

> 9. The SystemTap runtime library should provide the following functions:
> 	- _stp_flags_string() takes a bitmap and an array of name-value pairs. 
> [...]
> 	- _stp_strerror() takes an int [...]

Why should these be C runtime functions, instead of plain systemtap
functions?


Do you plan to recast a version of this particular tapset in the form
of the template I posted the other day?


- FChE

Attachment: pgp00000.pgp
Description: PGP signature