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
> [EMAIL PROTECTED]
>
>
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
>
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
