Why is the syscall read argument null?

Question

The dtrace

dtrace -n 'syscall::read:entry { @[fds[arg0].fi_fs] = count(); }'

I want to find the argument read fds

trace -lvn 'syscall::*read*:entry'


 933    syscall                                       read_nocancel entry

    Probe Description Attributes
        Identifier Names: Private
        Data Semantics:   Private
        Dependency Class: ISA

    Argument Attributes
        Identifier Names: Private
        Data Semantics:   Private
        Dependency Class: ISA

    Argument Types
        None

  963    syscall                                      readv_nocancel entry

    Probe Description Attributes
        Identifier Names: Private
        Data Semantics:   Private
        Dependency Class: ISA

    Argument Attributes
        Identifier Names: Private
        Data Semantics:   Private
        Dependency Class: ISA

    Argument Types
        None

  969    syscall                                      pread_nocancel entry

    Probe Description Attributes
        Identifier Names: Private
        Data Semantics:   Private
        Dependency Class: ISA

    Argument Attributes
        Identifier Names: Private
        Data Semantics:   Private
        Dependency Class: ISA

    Argument Types
         None

But the argument is None. How to find the arguments?

Answer 1

You are confusing the meaning of an argument with the type of an argument.

The meaning of an argument depends on the provider. If you want to learn about syscall::: probes then you need to consult the documentation for the syscall provider, which says

Arguments

For entry probes, the arguments (arg0 .. argn) are the arguments to the system call. For return probes, both arg0 and arg1 contain the return value. A non-zero value in the D variable errno indicates system call failure.

Therefore in the clause

syscall::read:entry
{
    ...
}

, which corresponds to

ssize_t read(int fildes, void *buf, size_t nbyte);

, arg0 would be the value of fildes, arg1 would be the value of buf and arg2 would be the value of nbyte.

The type of arg0, arg1, arg2 etc. is always an int64_t, regardless of the types of the arguments that they represent. This is enough for scalar quantities, but for a structure dtrace(1) needs to understand types. It's possible to cast arguments, e.g.

((struct mystruct *)(arg0))->my_member

but this is irritating. Sometimes, but not always, DTrace knows the types of the arguments themselves and allows them to be described using the notation args[0], args[1] etc.; thus under certain circumstances I could instead write the much more convenient

args[0]->my_member

For the syscall provider, DTrace doesn't know the arguments' types, which is why you see

# dtrace -lv -n syscall::read:entry
    ...
    Argument Types
        None

#

and why

dtrace -n 'syscall::read:entry {trace(args[0])}'

is not valid.

For the io provider, however, DTrace does know the arguments' types, e.g.

# dtrace -lv -n io:::start
    ... 
    Argument Types
        args[0]: bufinfo_t *
        args[1]: devinfo_t *
        args[2]: fileinfo_t *

#

By reading the documentation for the io provider one can see that the definition of a bufinfo_t includes

typedef struct bufinfo {
    ...
    size_t b_bcount;                /* number of bytes */
    ...
} bufinfo_t;

and this allows one to write, e.g.

dtrace -n 'io:::start {trace(args[0]->b_bcount)}'.

Finally, you mention fds[]. As I explained before, the type of fds[n] is fileinfo_t *.

I recommend that you follow this introduction.

Answer 2

How about man 2 read? On Mac OS, I get this:

READ(2)                     BSD System Calls Manual                    READ(2)

NAME
     pread, read, readv -- read input

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <sys/types.h>
     #include <sys/uio.h>
     #include <unistd.h>

     ssize_t
     pread(int d, void *buf, size_t nbyte, off_t offset);

     ssize_t
     read(int fildes, void *buf, size_t nbyte);

     ssize_t
     readv(int d, const struct iovec *iov, int iovcnt);
...

This will obviously only work for the syscall provider, however.