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
On Wed, Oct 01, 2008 at 12:16:07AM -0500, Nicolas Williams wrote:
pid$1:libsomelibrary:some_function:entry
{
self-some_item = copyin_expr(arg[0]-field1-field2-field3);
...
}
and the D *compiler* looking up the CTF for this and figuring out what
sequence of copyins to translace
On Wed, Oct 01, 2008 at 12:02:04PM -0700, Paul Macknee wrote:
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
On Wed, Oct 01, 2008 at 12:59:15PM -0700, Adam Leventhal wrote:
On Wed, Oct 01, 2008 at 12:16:07AM -0500, Nicolas Williams wrote:
pid$1:libsomelibrary:some_function:entry
{
self-some_item = copyin_expr(arg[0]-field1-field2-field3);
...
}
and the D *compiler* looking up the
On Wed, Oct 01, 2008 at 01:00:52PM -0700, Adam Leventhal wrote:
On Wed, Oct 01, 2008 at 12:02:04PM -0700, Paul Macknee wrote:
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
Hey Paul,
Thanks for the info - I guess this sort of is asking for it, but
exactly how did you know that 5 was the right number to grep for,
aside from knowing the kernel?
Take a look a that link in my last message -- it's the source code for
the
fsat system call. You'll see that code 5
On Sep 30, 2008, at 8:03 PM, Paul Macknee wrote:
Perhaps this would be an opportunity for a third party to build
some layered
software to implement your suggestion. That is, one could write a
program
that consumed CTF data to generate a D script that did what you
described.
Great,
On Mon, Sep 29, 2008 at 05:26:43PM -0700, Paul Macknee wrote:
Just out of curiosity, I did a
dtrace -n 'syscall:::entry { @num[execname, probefunc] = count(); }'
and looked at the entries produced by 'rm'.
I see everything that rm did, *except* the unlinkat - which is unfortunate
