Table of Contents
provides tracing and debugging facilities.
It allows one process (the process) to control another (the process).
Most of the time, the traced process runs normally, but when it receives
a signal see it stops. The tracing process is expected to notice this
via or the delivery of a signal, examine the state of the stopped process,
and cause it to terminate or continue as appropriate. is the mechanism
by which all this happens. The 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 calls are made by the
tracing process, and the argument specifies the process ID of the traced
process. can be: This request is the only one used by the traced process;
it declares that the process expects to be traced by its parent. All the
other arguments are ignored. (If the parent process does not expect to
trace the child, it will probably be rather confused by the results; once
the traced process stops, it cannot be made to continue except via When
a process has used this request and calls or any of the routines built
on it such as it will stop before executing the first instruction of
the new image. Also, any setuid or setgid bits on the executable being executed
will be ignored. These requests read a single of data from the traced
process’ address space. Traditionally, has allowed for machines with distinct
address spaces for instruction and data, which is why there are two requests:
conceptually, reads from the instruction space and reads from the data
space. In the current NetBSD implementation, these two requests are completely
identical. The argument specifies the address (in the traced process’ virtual
address space) at which the read is to be done. This address does not have
to meet any alignment constraints. The value read is returned as the return
value from These requests parallel and except that they write rather
than read. The argument supplies the value to be written. This request
reads an from the traced process’ user structure. The argument specifies
the location of the int relative to the base of the user structure; it
will usually be an integer value cast to either explicitly or via the
presence of a prototype for Unlike and must be aligned on an boundary.
The value read is returned as the return value from This request writes
an into the traced process’ user structure. specifies the offset, just
as for and specifies the value to be written, just as for and The
traced process continues execution. is an address specifying the place
where execution is to be resumed (a new value for the program counter),
or to indicate that execution is to pick up where it left off. provides
a signal number to be delivered to the traced process as it resumes execution,
or 0 if no signal is to be sent. The traced process terminates, as if
had been used with given as the signal to be delivered. This request allows
a process to gain control of an otherwise unrelated process and begin tracing
it. It does not need any cooperation from the to-be-traced process. In this
case, specifies the process ID of the to-be-traced process, and the other
two arguments are ignored. This request requires that the target process
must have the same real UID as the tracing process, and that it must not
be executing a setuid or setgid executable. (If the tracing process is
running as root, these restrictions do not apply.) The tracing process
will see the newly-traced process stop and may then control it as if it
had been traced all along. This request is like PT_CONTINUE, except that
it does not allow specifying an alternate place to continue execution,
and after it succeeds, the traced process is no longer traced and continues
execution normally. Additionally, machine-specific requests can exist.
On the SPARC, these are: This request reads the traced process’ machine
registers into the (defined in pointed to by This request is the converse
of it loads the traced process’ machine registers from the (defined in
pointed to by This request reads the traced process’ floating-point registers
into the (defined in pointed to by This request is the converse of
it loads the traced process’ floating-point registers from the (defined
in pointed to by This request is like except that the process will
stop next time it executes any system call. Information about the system
call can be examined with and potentially modified with through the
element of the user structure (see below). If the process is continued
with another request, it will stop again on exit from the syscall, at
which point the return values can be examined and potentially changed.
The element is of type which should be declared by including and and
contains the following fields (among others): When a process
stops on entry to a syscall, holds the number of the syscall, holds the
number of arguments it expects, and holds the arguments themselves. (Only
the first elements of are guaranteed to be useful.) When a process stops
on exit from a syscall, is holds the error number see or 0 if no
error occurred, and holds the return values. (If the syscall returns only
one value, only is useful.) The tracing process can modify any of these
with only some modifications are useful. On entry to a syscall, 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 appropriately
for the new call, but there is no need to modify If the new syscall
number is 0, no syscall is actually performed; instead, and 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 error is effectively performed. On exit from a syscall,
only and 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.
Some requests can cause to return as
a non-error value; to disambiguate, can be set to 0 before the call and
checked afterwards. The possible errors are: No process having the specified
process ID exists. A process attempted to use on itself. The was not
one of the legal requests. The to or was not The signal number (in
to or was neither 0 nor a legal signal number. or was attempted
on a process with no valid register set. (This is normally true only of
system processes.) was attempted on a process that was already being
traced. A request attempted to manipulate a process that was being traced
by some process other than the one making the request. A request (other
than specified a process that wasn’t stopped. A request (other than
attempted to manipulate a process that wasn’t being traced at all. An attempt
was made to use on a process in violation of the requirements listed under
above.
On the SPARC, the PC is set to the provided PC value for and
similar calls, but the NPC is set willy-nilly to 4 greater than the PC value.
Using and to modify the PC, passing to should be able to sidestep
this. Single-stepping is not available. When using 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
Table of Contents