.\" Copyright (c) 1980, 1993
.\" The Regents of the University of California. All rights reserved.
.\" %sccs.include.proprietary.roff%
.\" @(#)ptrace.2 8.1 (Berkeley) %G%
ptrace(request, pid, addr, data)
int request, pid, *addr, data;
provides a means by which a parent process
may control the execution of a child process,
and examine and change its core image.
Its primary use is for the implementation of breakpoint debugging.
There are four arguments whose interpretation
is the process ID of the traced process,
which must be a child (no more distant descendant)
behaves normally until it encounters some signal
whether internally generated
like \*(lqillegal instruction\*(rq or externally
generated like \*(lqinterrupt\*(rq.
Then the traced process enters a stopped state
and its parent is notified via
When the child is in the stopped state,
its core image can be examined and modified
request can then cause the child either to terminate
or to continue, possibly ignoring the signal.
argument determines the precise
This request is the only one used by the child process;
it declares that the process is to be traced by its parent.
All the other arguments are ignored.
Peculiar results will ensue
if the parent does not expect to trace the child.
word in the child process's address space
If I and D space are separated (e.g. historically
on a pdp-11), request PT_READ_I indicates I space,
must be even on some machines.
The child must be stopped.
of the system's per-process data area corresponding to
must be even on some machines and less than 512.
This space contains the registers and other information about
its layout corresponds to the
is written at the word in the process's address space corresponding to
which must be even on some machines.
No useful value is returned.
If I and D space are separated, request PT_WRITE_I indicates I space,
Attempts to write in pure procedure
fail if another process is executing the same file.
The process's system data is written,
as it is read with request PT_READ_U.
Only a few locations can be written in this way:
the floating point status and registers,
and certain bits of the processor status word.
argument is taken as a signal number
and the child's execution continues
as if it had incurred that signal.
Normally the signal number will be
either 0 to indicate that the signal that caused the stop
or that value fetched out of the
process's image indicating which signal caused
is (int *)1 then execution continues from where it stopped.
The traced process terminates.
Execution continues as in request PT_CONTINUE;
however, as soon as possible after execution of at least one instruction,
The signal number from the stop is
(On the VAX-11 the T-bit is used and just one instruction
This is part of the mechanism for implementing breakpoints.
is re-parented to the calling process and delivered a SIGSTOP signal.
The child process may then be traced by the parent, as in PT_TRACE_ME.
A process already being traced cannot be attached to.
If the calling process is not owned by root,
it must have the same real user ID as the target process and
not have used set user or group priviledges.
is detached from tracing and continues its execution.
The process, which must be a traced child of the caller, is re-parented
with the parent it had before tracing began. The
arguments behave as in PT_CONTINUE.
(except for request PT_TRACE_ME)
can be used only when the subject process has stopped.
call is used to determine
in such a case the \*(lqtermination\*(rq status
has the value 0177 to indicate stoppage rather
than genuine termination.
To forestall possible fraud,
inhibits the set-user-id and set-group-id facilities
If a traced process calls
it will stop before executing the first instruction of the new image
On a VAX-11, \*(lqword\*(rq also means a 32-bit integer,
restriction does not apply.
A 0 value is returned if the call succeeds. If the call fails
then a \-1 is returned and the global variable \fIerrno\fP is
set to indicate the error.
The request code is invalid.
The specified process does not exist.
The given signal number is invalid.
The specified address is out of bounds.
The specified process cannot be traced.
wait(2), sigvec(2), adb(1)
is unique and arcane; it should be replaced with a special file that
can be opened and read and written.
The control functions could then be implemented with
This would be simpler to understand and have much better performance.
The request PT_TRACE_ME call should be able to specify signals that
are to be treated normally and not cause a stop.
In this way, for example, programs with simulated floating point
(which use \*(lqillegal instruction\*(rq signals at a very high rate)
could be efficiently debugged.
The error indication, \-1, is a legitimate function value;
can be used to disambiguate.
It should be possible to stop a process on occurrence of a system
in this way a completely controlled environment could
PT_STEP is not supported on all architectures.
For example, the SPARC architecture does not have a trace bit, which
complicates single instruction stepping.
Debuggers and the like can emulate PT_STEP by placing breakpoints at
all possible locations of the next instruction.