dtrace discuss - Mar 2008 - Can dtrace match on parameter type on entry?

As dtrace uses C type information stored in the object
files, which we can use with args[#] and printing, is
it possible to use this for matching?  (via an enhancement.)

So, could it be possible to do:

dtrace -n ''fbt:::entry/mblk_t* == 0x3a0a0a0a0a0/{}''

What this would do is:
* find all of the functions that have an "mblk_t *" in
  their parameter list;
* find out which positions in the parameter list the
  mblk_t* is and
* match against all parameters that are mblk_t*''s with
  0x3a0a0a0a0a0.

Thoughts?
Am I crazy for imagining this?
Or is it already an RFE somewhere?

Darren

On Wed, Mar 19, 2008 at 06:50:59PM -0700, Darren Reed
wrote:
> As dtrace uses C type information stored in the object
> files, which we can use with args[#] and printing, is
> it possible to use this for matching?  (via an enhancement.)
> 
> So, could it be possible to do:
> 
> dtrace -n ''fbt:::entry/mblk_t* == 0x3a0a0a0a0a0/{}''
> 
> What this would do is:
> * find all of the functions that have an "mblk_t *" in
>   their parameter list;
> * find out which positions in the parameter list the
>   mblk_t* is and
> * match against all parameters that are mblk_t*''s with
>   0x3a0a0a0a0a0.
> 
> Thoughts?
> Am I crazy for imagining this?
> Or is it already an RFE somewhere?
> 
> Darren
That''s spicy.  It''s not really possible right now, but it is
possible
to implement.  The best way to do it would be to add typeof() to D,
which I had considered a while ago.

This would permit something like this:

fbt:::entry
/typeof(args[0]) == typeof (mblk_t *) && arg0 == 0x3a0a0a0a0a0/
{
	...
}

and then rinse and repeat for the remainder of the args[] indices.

This is at least feasible although it requires both
kernel and compiler modifications.

Basically what would happen is that in the compiler typeof
would emit DIF corresponding to a CTF container and type ID reference
and then we have access to same in the kernel.

The hard part is that the dtps_argdesc callback for providers cannot
execute in probe context, so this data would have to be cached
somewhere during probe registration.

-Mike

-- 
Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/

On Wed 19 Mar 2008 at 07:11PM, Mike Shapiro wrote:
> On Wed, Mar 19, 2008 at 06:50:59PM -0700, Darren Reed wrote:
> > As dtrace uses C type information stored in the object
> > files, which we can use with args[#] and printing, is
> > it possible to use this for matching?  (via an enhancement.)
> > 
> > So, could it be possible to do:
> > 
> > dtrace -n ''fbt:::entry/mblk_t* == 0x3a0a0a0a0a0/{}''
> > 
> > What this would do is:
> > * find all of the functions that have an "mblk_t *" in
> >   their parameter list;
> > * find out which positions in the parameter list the
> >   mblk_t* is and
> > * match against all parameters that are mblk_t*''s with
> >   0x3a0a0a0a0a0.
> > 
> > Thoughts?
> > Am I crazy for imagining this?
> > Or is it already an RFE somewhere?
> > 
> > Darren
> 
> That''s spicy.  It''s not really possible right now, but it
is possible
> to implement.  The best way to do it would be to add typeof() to D,
> which I had considered a while ago.
I was thinking that one could post-process the output of ''dtrace
-lv''
(or write a little Java/DTrace API program) which could determine this
information the "hard way", and then generate the expanded-form D
program, like (roughly) this:

/* Things that take mblk_t''s in args[1] */
fbt:vni:vniwput:entry,
fbt:aggr:aggr_wput:entry,
...
/args[1] ==  0x3a0a0a0a0a0/
{
}

Would that suffice?

In other words, use a fancy preprocessing step to generate the program
you want.

        -dp

-- 
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp

On Thu, Mar 20, 2008 at 12:06:11AM -0800, Rich Morin
wrote:
> At 19:11 -0700 3/19/08, Mike Shapiro wrote:
> > The best way to do it would be to add typeof() to D,
> > which I had considered a while ago.
> 
> I would _really_ like to have a typeof() function, though my
> reason is rather different.  Currently, in DT_Logger, I have to
> use a different probe for each unique system call "signature" I
> encounter.  So, for example, I handle open(2) by a probe whose
> signature is SNNn (String, Number, Number, numeric return value).
> 
> With a typeof() function, I could test the types of parameters
> and process them as needed.  Of course, having if/then/else as
> syntactic sugar would make that MUCH easier to write (and read).
Ok, good to know.
 
> Of course, I could avoid the whole issue if there were a to_s()
> function (translate whatever this is into a string), such as
> Ruby provides.  Then I could treat all variables as strings.
Agree that would be useful.
 
> If you _really_ want to be helpful, you could provide a way to
> do percent-encoding of oddball (eg, control and 8-bit) bytes.
> Given that I currently have to assume that any character could
> be anything from 1-377, I''m forced to use counted strings, as:
> 
>   foo=13''Hello, world.''
> 
> With percent-encoding, I could emit YAML directly from D.
> 
> -r
Can you explain this one further?  We accept input string literals
using ANSI / ISO-C escapes (hex or octal), like this:

string s = "foo\x12\0177"

and %S format character from printf() will print them back out that way.

Or did you need something else?

-Mike

-- 
Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/

At 19:11 -0700 3/19/08, Mike Shapiro wrote:
> The best way to do it would be to add typeof() to D,
> which I had considered a while ago.
I would _really_ like to have a typeof() function, though my
reason is rather different.  Currently, in DT_Logger, I have to
use a different probe for each unique system call "signature" I
encounter.  So, for example, I handle open(2) by a probe whose
signature is SNNn (String, Number, Number, numeric return value).

With a typeof() function, I could test the types of parameters
and process them as needed.  Of course, having if/then/else as
syntactic sugar would make that MUCH easier to write (and read).


Of course, I could avoid the whole issue if there were a to_s()
function (translate whatever this is into a string), such as
Ruby provides.  Then I could treat all variables as strings.

If you _really_ want to be helpful, you could provide a way to
do percent-encoding of oddball (eg, control and 8-bit) bytes.
Given that I currently have to assume that any character could
be anything from 1-377, I''m forced to use counted strings, as:

  foo=13''Hello, world.''

With percent-encoding, I could emit YAML directly from D.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

At 00:16 -0700 3/20/08, Mike Shapiro wrote:
>> With percent-encoding, I could emit YAML directly from D.
>
> Can you explain this one further?  We accept input string
> literals using ANSI / ISO-C escapes (hex or octal), like this:
>
> string s = "foo\x12\0177"
>
> and %S format character from printf() will print them back
> out that way.
>
> Or did you need something else?
All I need is something that can be used to generate YAML
strings, as:

  foo: ''Hello, world.''

making sure that YAML never sees anything that confuses it
(eg, 001-037, 200-277, "''").  If %S does this, I''m
happy...

-r

-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

I just looked in the SDTG and see the following:

S   The argument must be an array of char or a string.
    The argument is processed as if by the %s conversion,
    but any ASCII characters that are not  printable are
    replaced by the corresponding escape sequence
    described in Table 2-5.

TABLE 2-5 D Character Escape Sequences
\a alert              \\ backslash
\b backspace          \? question mark
\f formfeed           \'' single quote
\n newline            \" double quote
\r carriage return    \0oo octal value 0oo
\t horizontal tab     \xhh hexadecimal value 0xhh
\v vertical tab       \0 null character


Looks very promising...

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

Dan Price wrote:
>On Wed 19 Mar 2008 at 07:11PM, Mike Shapiro wrote:
>  
>
>>On Wed, Mar 19, 2008 at 06:50:59PM -0700, Darren Reed wrote:
>>    
>>
>>>As dtrace uses C type information stored in the object
>>>files, which we can use with args[#] and printing, is
>>>it possible to use this for matching?  (via an enhancement.)
>>>
>>>So, could it be possible to do:
>>>
>>>dtrace -n ''fbt:::entry/mblk_t* ==
0x3a0a0a0a0a0/{}''
>>>
>>>What this would do is:
>>>* find all of the functions that have an "mblk_t *" in
>>>  their parameter list;
>>>* find out which positions in the parameter list the
>>>  mblk_t* is and
>>>* match against all parameters that are mblk_t*''s with
>>>  0x3a0a0a0a0a0.
>>>
>>>Thoughts?
>>>Am I crazy for imagining this?
>>>Or is it already an RFE somewhere?
>>>
>>>Darren
>>>      
>>>
>>That''s spicy.  It''s not really possible right now, but
it is possible
>>to implement.  The best way to do it would be to add typeof() to D,
>>which I had considered a while ago.
>>    
>>
>
>I was thinking that one could post-process the output of ''dtrace
-lv''
>(or write a little Java/DTrace API program) which could determine this
>information the "hard way", and then generate the expanded-form D
>program, like (roughly) this:
>
>/* Things that take mblk_t''s in args[1] */
>fbt:vni:vniwput:entry,
>fbt:aggr:aggr_wput:entry,
>...
>/args[1] ==  0x3a0a0a0a0a0/
>{
>}
>
>Would that suffice?
>  
>
Hmmm.  I''m not accustomed to using a preprocessor with dtrace...

Let me work this through..

To also talk to what Michael suggested, I think that''s definately an
improvement on the idea I originally suggested, as dtrace doesn''t
have an if() and if you only had "/mblk_t == ../" then you
wouldn''t
be able to detect which arg was responsible.

With respect to using preprocessing, what I want from my D script
is the ability to have "#!/usr/sbin/dtrace -s" at the top of my file
and
the rest in D.  That''s requirement #1, so that when I do "file
foo",
I know what it is.

There''s definately a "workaround" that, as you''ve
suggested, could
use the output of what''s currently available and make something
work, but a primary goal here is convenience.

On the other hand, if I could specify a preprocessor on the
"#!/usr/sbin/dtrace" line that would do the work you''re
describing
then that might also work too... but then it might become more
difficult to debug script errors, too, because line number meaning
is lost.

Additionally, the size of the D program is much larger with the
preprocessed result and rather than having 100s of dtrace
probes point to a single D function, you end up having 100s of
probes with identical functions.

To merge the two ideas, it would be interesting if when you said
"fbt:::entry/typeof (arg0) == mblk_t*/" that dtrace would only put
probes on functions that match this rather than trap every entry
and do a compare then...so in this example, the // for matching
type would become a no-op once the probes are inserted.

Darren