dtrace discuss - Feb 2008 - Can DTrace display non-instrumented function argument counts and types?

Is it possible to use DTrace to display the number of arguments and their types
for userland or kernel functions that are not explicitly instrumented or
documented by their authors?  We''re talking about functions provided by
Veritas VxVM/VxFS and the like, and for example, we might want to try tracing
I/Os from App => VxFS => VxVM => ssd driver to see where I/Os get
aggregated or broken up.  But without being able to determine function
signatures, it will be very hard to even begin such a process.

It would seem that this is possible, but I haven''t seen any examples of
such a use.  I''m presuming that this would be done via fbt.

Gordon Marler
gmarler at gmarler.com


--
This message posted from opensolaris.org

For kernel modules, _if_ the supplied kernel code (driver, file system, 
whatever),
was compiled with symbolic information, you can determine the argument list
and types with mdb:

# mdb -k
Loading modules: [ unix genunix specfs dtrace uppc pcplusmp scsi_vhci 
ufs mpt ip hook neti sctp arp usba fctl nca lofs zfs random audiosup 
sppp ptm crypto ipc md cpc fcip fcp logindmux nsctl sdbc sv ii rdc ]
 >ufs_read::nm -f ctype
C Type                                           
int (*)(struct vnode *, struct uio *, int, struct cred *, struct 
caller_context *)

The example above displays the arg list for the kernel ufs_read() 
function. You can also
determine structure members:

 > ::print -t struct vnode
{
    kmutex_t v_lock {
        void *[2] _opaque
    }
    uint_t v_flag
    uint_t v_count
    void *v_data
    struct vfs *v_vfsp
. . .

If that works (meaning the kernel module was indeed compiled with 
symbolic type information),
you can use dtrace to instrument the entry points in the kernel 
functions of interest,
and grab arguments using either the args[] array (typed data) or 
args0...args1...etc (int64_t''s).

HTH,
/jim


Gordon Marler wrote:
> Is it possible to use DTrace to display the number of arguments and their
types for userland or kernel functions that are not explicitly instrumented or
documented by their authors?  We''re talking about functions provided by
Veritas VxVM/VxFS and the like, and for example, we might want to try tracing
I/Os from App => VxFS => VxVM => ssd driver to see where I/Os get
aggregated or broken up.  But without being able to determine function
signatures, it will be very hard to even begin such a process.
>
> It would seem that this is possible, but I haven''t seen any
examples of such a use.  I''m presuming that this would be done via fbt.
>
> Gordon Marler
> gmarler at gmarler.com
>
>
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>

Can''t get quite that far - note that mdb doesn''t load the vxfs
module by default even if VxVM/VxFS are installed and in use on the machine -
haven''t been able to figure out how to load it manually either - using
::load /kernel/fs/sparcv9/vxfs gets me a "page_downgrade: referenced symbol
not found" error.  I''m guessing that I have to load some other
module first - just not clear which one.
> For kernel modules, _if_ the supplied kernel code
> (driver, file system, 
> whatever),
> was compiled with symbolic information, you can
> determine the argument list
> and types with mdb:
> 
> # mdb -k
> Loading modules: [ unix genunix specfs dtrace uppc
> pcplusmp scsi_vhci 
> ufs mpt ip hook neti sctp arp usba fctl nca lofs zfs
> random audiosup 
> sppp ptm crypto ipc md cpc fcip fcp logindmux nsctl
> sdbc sv ii rdc ]
>  >ufs_read::nm -f ctype
>  Type                                           
> nt (*)(struct vnode *, struct uio *, int, struct cred
> *, struct 
> caller_context *)
>

--
This message posted from opensolaris.org