Re: Sample tapset source file

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Tue, 2005-04-19 at 09:45, Frank Ch. Eigler wrote:
> 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.

A user script can't reference them because they're declared static.  In
fact, if we require the tapset author to put such functions in a
separate source file, they'll have to be extern, and there'll be no
control over which modules call them.

And anyway, I thought we'd sort of agreed that a non-expert script can't
call C functions.

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

Because I didn't need a different example to implement what I was trying
to implement.  I honestly don't know whether accessing
filp->f_dentry->d_name.name is always safe in that context.  As a
thought exercise, consider a similar situation where in order to get at
the exported value, you really do need to acquire and release a lock.

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

Consider locking.  See above.

Consider what you'd have to add to the systemtap language to provide a
script access to the auxiliary C functions, macro-ized values, and other
identifiers that will inevitably be needed.

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

It's not intended to be whitespace-sensitive.  In the sample tapset, the
.probename clause is on a separate line solely for legibility.  If this
isn't what you had in mind, please explain.

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

You (or your clients) may want to define different handlers for the same
probepoint, to be used under different circumstances.  Seems like
motivation enough.

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

Correct.

> 
> > [...]
> > 	- $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.

For PC-based probepoints, it can be determined at compile time.

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

I haven't given it much thought.  Perhaps probename (or probepoint
specification) and handler name?

We should also think about what tags need to be added to binary records
(asuming we'll generated them under at least some circumstances) to
allow them to be sorted out in user space.

> 
> > 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?
> 
The latter could certainly be implemented using an associative array,
but you'd have to pay the setup cost of populating the array.

The former would be tougher to implement predictably (e.g., getting the
flags in a predictable order) using an associative array.

In both cases, I bet the C implementation would be simpler and more
efficient.  Whether the outside world sees these functions as C runtime
functions or systemtap functions doesn't matter much to me.

Of course, we haven't really talked about what the tapset client can see
(sort of analogous to a C header file or C++ class definition) in order
to know and access what's actually provided by the tapset.

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

I can do that, but I may not before tomorrow's meeting.

> 
> - FChE

Thanks for the comments.

Jim