The Fa request argument specifies what operation is being performed; the meaning of the rest of the arguments depends on the operation, but except for one special case noted below, all Fn ptrace calls are made by the tracing process, and the Fa pid argument specifies the process ID of the traced process. Fa request can be:
Additionally, machine-specific requests can exist. On the SPARC, these are:
When a process stops on entry to a syscall, syscall_num holds the number of the syscall, syscall_nargs holds the number of arguments it expects, and syscall_args holds the arguments themselves. (Only the first syscall_nargs elements of syscall_args are guaranteed to be useful.) When a process stops on exit from a syscall, syscall_num is Eo -1 Ec , syscall_err holds the error number Po see errno(2) Pc , or 0 if no error occurred, and syscall_rv holds the return values. (If the syscall returns only one value, only syscall_rv[0] is useful.) The tracing process can modify any of these with PT_WRITE_U only some modifications are useful.
On entry to a syscall, syscall_num can be changed, and the syscall actually performed will correspond to the new number (it is the responsibility of the tracing process to fill in syscall_args appropriately for the new call, but there is no need to modify Eo syscall_nargs Ec ). If the new syscall number is 0, no syscall is actually performed; instead, syscall_err and syscall_rv are passed back to the traced process directly (and therefore should be filled in). If the syscall number is otherwise out of range, a dummy syscall which simply produces an Er ENOSYS error is effectively performed.
On exit from a syscall, only syscall_err and syscall_rv can usefully be changed; they are set to the values returned by the syscall and will be passed back to the traced process by the normal syscall return mechanism.
Single-stepping is not available.
When using PT_SYSCALL there is no easy way to tell whether the traced process stopped because it made a syscall or because a signal was sent at a moment that it just happened to have valid-looking garbage in its ``struct mdproc ''