Re: what is a tapset? [RE: Skeleton detailed design document]

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

Hi -


On Fri, Apr 01, 2005 at 03:18:08PM -0800, Chen, Brad wrote:
> [...]
> >Looks okay, except that I am not sure that the "tapset" constructs
> >I've seen so far need *any* C code (custom headers or libraries).  [...]
>
> It makes sense to me that any tapset that simply used 
> [kjr]probes could be done in script rather than C. [...]
> it might be nice to compile the tapset defn once and 
> reference an object file or library, rather than 
> recompiling a potentially large body of script. [...]

This type of optimization is worth exploring, though I expect
normal translation and compilation times to be short enough
for such tricks not to be necessary.


> Here are some kinds of tapsets which might require C
> code:
> - time-based interrupts. [...]
>   Seems like C code would be required for the underlying
>   timer implementation. I could imagine putting an API
>   into the Systemtap runtime along the lines of: [...]
> 	ST_Interrupt(100ms, handler);

Indeed, but we can hard-code support for a set of these within the
systemtap translator and/or the runtime.  I guess I wonder how many
such event- or breakpoint-related APIs we might need to support
*without* extending systemtap nor the runtime.  This could allow
constraining third party tapsters to script authorship only and
thus simplify the system.


> [...]
> - In general, different CPUs will have different 'special' 
>   instructions. If tapsets could have C code, access to 
>   these special instructions could go in a machine-dependent
>   tapset. If not, we would have to build more machine
>   dependencies into the systemtap runtime. [...]

Indeed.  I suspect both of these are reasonable things to do.
If the former were accomplished by embedding of C code within
special probe scripts, we could have it all.


> [...]  Jprobes provide for instrumenting procedures and accessing
> procedure call arguments.

Yes, but this capability (as distinct from kprobes) is not directly
relevant to function address lookup.

> Also, Will has posted a couple examples of how to get an address
> from a procedure name. [...]  For runtime resolution, Will's
> kprobe_funct_where.ko appears to use kallsyms_lookup_name(). [...]

Remember, all these sample probes are just demonstrations of
potential.  They don't use the sorts of mechanisms we will have
available in a translated realm.

> Is this adequate access to code symbols? It would be nice someday to
> be able to refer to file names and line numbers, but perhaps that
> should wait for a later release.

Definitely.  We mentioned this several times, referring to the issue
as being able to specify probe points in terms of "coordinates" such
as source locations.  We will need to decode the debugging information
stored in object files in order to map line numbers etc. to actual
run-time PC addresses, and we fully intend to support a variety of
such addressing methods.  Similarly, decoding debugging information
will allow the translator to resolve references to *data* such as
function parameters, global data, etc., without having to use the
jprobes signature-matching hack.  This part will be harder.

Review Vara's "coordinate" posting and its followups, or the current
src/TODO file, to get a sense of the variety.


- FChE