dtrace discuss - Sep 2007 - how to obtain the info about args of a probe?

Dear all:

With "dtrace -l -P xxx | grep yyy", I could only learn the potential
prov:mod:func:name useful to me.
But it doesn''t present and describe the args of these probes. And
there''re
no info about these probes in the doc "Dynamic Tracing Guide".
For example:
 3813        sdt           genunix                      taskq_thread
taskq-exec-end
 3814        sdt           genunix                      taskq_thread
taskq-exec-start
 3815        sdt           genunix                    taskq_dispatch
taskq-enqueue

Where can I obtain the args and its description of these secret probes?
Reading the related kernel source code?

TIA!


Regards,
TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070902/dc382270/attachment.html>

?? Tao Jie wrote:
> Dear all:
>  
> With "dtrace -l -P xxx | grep yyy", I could only learn the
potential
> prov:mod:func:name useful to me.
> But it doesn''t present and describe the args of these probes. And 
> there''re no info about these probes in the doc "Dynamic
Tracing Guide".
> For example:
>  3813        sdt           genunix                      taskq_thread 
> taskq-exec-end
>  3814        sdt           genunix                      taskq_thread 
> taskq-exec-start
>  3815        sdt           genunix                    taskq_dispatch 
> taskq-enqueue
>  
> Where can I obtain the args and its description of these secret probes?
> Reading the related kernel source code?
You can get types and number of arguments by adding -v, but for real 
documentation of what the types mean, you need docs or to reconstruct them 
from the source code.

> Dear all:
> 
> With "dtrace -l -P xxx | grep yyy", I could only learn the
potential
> prov:mod:func:name useful to me.
> But it doesn''t present and describe the args of these probes. And
there''re
> no info about these probes in the doc "Dynamic Tracing Guide".
> For example:
>  3813        sdt           genunix                      taskq_thread
> taskq-exec-end
>  3814        sdt           genunix                      taskq_thread
> taskq-exec-start
>  3815        sdt           genunix                    taskq_dispatch
> taskq-enqueue
> 
> Where can I obtain the args and its description of these secret probes?
> Reading the related kernel source code?
These probes are not secret, but there are implementation-specific and 
unstable, so they are not documented in the DTrace book. If you really want to 
know what these three mean and how to interpret their arguments, I''ll
be glad
to give you all the details.

- akolb

So If I wanted to get more information on syscall probe, what do I need to do?.
For example:
dtrace -v -l -P syscall | grep creat would yield the following result on my
system. The question then is what does creat entry and creat return do? Where do
I get more information on any probe?
77804    syscall                                               creat entry
77805    syscall                                               creat return
78068    syscall                                          lwp_create entry
78069    syscall                                          lwp_create return
78134    syscall                                        timer_create entry
78135    syscall                                        timer_create return
78192    syscall                                             creat64 entry
78193    syscall                                             creat64 return

Thanks.


--
This message posted from opensolaris.org

On Wed 12 Sep 2007 at 01:27PM, deniz rende wrote:
> So If I wanted to get more information on syscall probe, what do I
> need to do?. For example: dtrace -v -l -P syscall | grep creat would
> yield the following result on my system. The question then is what
> does creat entry and creat return do? Where do I get more information
> on any probe? 
It depends on the probe provider.  For most system calls, you can
use man(1) to learn more.  Using the source (at http://src.opensolaris.org)
is also very helpful.  So, ''man creat'' should help.

"entry" and "return" are pretty self explanatory: the first
fires
as the thread of execution begins to execute the system call, and
the latter probe fires when the system call has finished executing.

For fbt probes, the probes fire when the indicated kernel function
starts to run (entry) and finishes (return).  To learn about that
kernel function, see the source.

        -dp

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

On Wed 12 Sep 2007 at 01:47PM, Dan Price wrote:
> On Wed 12 Sep 2007 at 01:27PM, deniz rende wrote:
> > So If I wanted to get more information on syscall probe, what do I
> > need to do?. For example: dtrace -v -l -P syscall | grep creat would
> > yield the following result on my system. The question then is what
> > does creat entry and creat return do? Where do I get more information
> > on any probe? 
> 
> It depends on the probe provider.  For most system calls, you can
> use man(1) to learn more.  Using the source (at http://src.opensolaris.org)
> is also very helpful.  So, ''man creat'' should help.
> 
> "entry" and "return" are pretty self explanatory: the
first fires
> as the thread of execution begins to execute the system call, and
> the latter probe fires when the system call has finished executing.
> 
> For fbt probes, the probes fire when the indicated kernel function
> starts to run (entry) and finishes (return).  To learn about that
> kernel function, see the source.
I missed that you said "args" in your subject line-- sorry about
that.  Again, using the man pages and/or source can be helpful.
In the case of creat(2), we see this in the man page:

     int creat(const char *path, mode_t mode);

So, from that, we might try:

$ dtrace -n syscall::creat:entry''{ printf("%s
0%o",copyinstr(arg0), arg1) }''
CPU     ID                    FUNCTION:NAME
  0   3838                      creat:entry /tmp/qqqq 0666

The reason for the copyinstr is that the pointer passed into the creat
system call is still in the user address space of the process which
called creat(2).

(in another window I did ''/usr/ucb/touch /tmp/qqq''; I had to
hunt around
for a command which used creat(2)).

        -dp

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