Re: Sample tapset source file

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

Hi -

On Tue, Apr 19, 2005 at 01:32:31PM -0700, Jim Keniston wrote:
> [...]
> > 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.  [...]

I don't see why you're bringing up C linkage issues here.  The
translation process could proceed as if emitting a single large C
file.

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

We haven't actually agreed yet that a script can call C functions *at all*.


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

However, recall that probes that acquire locks present a deadlock
hazard.  Generally probes should avoid doing anything that may sleep.

I don't know how much relief from these constraints we should grant to
even guru-mode scripts such as those presumably located within a
script library.


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

Is this necessary, beyond the safe sorts of locking discussed
in <http://tinyurl.com/botp7>?

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

This inevitabilty is not obvious.  Why can't some specific essential
subset of these values be made accessible via translator modification
extensions, which could then impose additional typing or other
constraints?  Note that some macros and identifiers should be
accessible via debuginfo data.


> > > 4. Probepoints can be named using the probename("<name>") clause. 
> > > [...]
> > 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.  [...]

Your alias/probe-wrapper idea is pretty clever.  Here's an elaboration
of it, with a possible implementation strategy.  We could support an
additional probe declaration syntax:

    probe ALIAS.NAME = UNDERLYING.PROBE.POINT.NAME  { ... body ... }

Then later scripts would be able to use this construct to refer to it:

    probe ALIAS.NAME { ... body2 ... }

To "export" variables to the user "body2" routine, let's implement
such probe aliases as lexical replication of "body" within and before
"body2".  So "body" could include ordinary variable assignments, which
"body2" could then use.


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

How is this different from defining multiple probe points that might
happen to the same PC address?  What incremental value does a named
handler give?  How do you imagine user scripts refer to them
separately?  Or is this another case of aliasing?


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

Please explain what kinds of binary records you are referring to.


> [...]

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

Think about it analogously to what a gdb user might be able to see,
upon hitting a breakpoint at the associated address.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature