Re: new syscall tapset checked in, but needs work

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

Hi -

Josh wrote:
> [...]
> Interesting idea - just to be explicit, is this what you had in mind?

Yes.

> [...]
> Then person using the tapset would do something like:
> probe syscall.read { /* capture arguments */ }
> probe syscall.read.return {
>     printf("read(%s) =3D %s\n", argstr, errno_str(returnval()))
> }

It could be even smarter than that.  One can build a higher level
tapset on top of a lower level one: one specifically for tracing.
Tapset scripts are not constrained to only export functions or probe
aliases.  They can include active probes and exported global variables
too.

For example, a new "syscall-trace-read.stp" file could include both
those probes, and export a single dummy identifier (global, or
function) that, if referenced from an end-user script, would make the
translator pull in the whole file, and activate those probes.  (The
granularity of automatic inclusion is the .stp file, so a more clever
arrangement may be necessary to enable tracing without having to have
200-odd files.  Maybe grouping them?)


> This only works if there's only one instance of the return probe [...]

Yes, we need to make the maxactive parameters of e.g. systemcall
retprobes high enough to account for multiple threads blocking in one.


> By the way, I tried it without accessing the args, and the optimizer
> didn't clean it up. [...]  perhaps the optimizer isn't handling
> delete statements?

Yes, that's it.  An easy way around that for now would be to use an
ordinary assignment (=0 or ="") to clear the array slot, which renders
it released.

- FChE