> Why would you want to do this as a "dtrace function"? This seems like a
> preprocessing step that you'd want to do statically rather than at
> runtime.
Suppose I want to make a simple function - a 'truss lite' as it were - which
does an aggregation of all system calls and their arguments, in human readable
form. With a dumper-like function - and an expression which expands all
arguments, you could say:
syscall:::entry
{
@[ execname, probefunc, stringify(probefunc, @arg) ] = count();
}
In stringify - if I could write it - I could keep in one place all of the
functionality for parsing, ignoring, or passing through the arguments that come
into the syscall.
I could then reuse that functionality in other places - say in an printf, which
I could use in any probe, or in other scripts.
The alternative I see, is to need to know the usage about each syscall (all
hundreds of them) and write hundreds of separate probes that know how the
arguments are to be parsed. As it is, if I even try to do intelligent
preprocessing:
syscall:::entry
{
@[ execname, probefunc, copyinstr(arg0)] = count();
}
this complains loudly (as it should) about dereferencing errors.
I'm open to suggestions on how to write something like the above using the
current dtrace - so - how would you do it using the current dtrace, using your
'preprocessing' method, and assuming that I want to reuse the functionality,
potentially, in other scripts?
Thanks,
Paul
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
[email protected]
