Why is the syscall read argument null? - dtrace

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.