This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: new syscall tapset checked in, but needs work
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