2 .\" $NetBSD: ptrace.2,v 1.2 1995/02/27 12:35:37 cgd Exp $
4 .\" This file is in the public domain.
10 .Nd process tracing and debugging
17 .Fn ptrace "int request" "pid_t pid" "caddr_t addr" "int data"
22 provides tracing and debugging facilities.
31 The tracing process must first attach to the traced process, and then
34 system calls to control the execution of the process, as well as access
35 process memory and register state.
36 For the duration of the tracing session, the traced process will be
38 with its parent process ID (and resulting behavior)
39 changed to the tracing process.
40 It is permissible for a tracing process to attach to more than one
41 other process at a time.
42 When the tracing process has completed its work, it must detach the
43 traced process; if a tracing process exits without first detaching all
44 processes it has attached, those processes will be killed.
46 Most of the time, the traced process runs normally, but when it
51 The tracing process is expected to notice this via
55 signal, examine the state of the stopped process, and cause it to
56 terminate or continue as appropriate.
57 The signal may be a normal process signal, generated as a result of
58 traced process behavior, or use of the
60 system call; alternatively, it may be generated by the tracing facility
61 as a result of attaching, system calls, or stepping by the tracing
63 The tracing process may choose to intercept the signal, using it to
64 observe process behavior (such as
66 or forward the signal to the process if appropriate.
70 is the mechanism by which all this happens.
74 argument specifies what operation is being performed; the meaning of
75 the rest of the arguments depends on the operation, but except for one
76 special case noted below, all
78 calls are made by the tracing process, and the
80 argument specifies the process ID of the traced process
81 or a corresponding thread ID.
88 This request is the only one used by the traced process; it declares
89 that the process expects to be traced by its parent.
90 All the other arguments are ignored.
91 (If the parent process does not expect to trace the child, it will
92 probably be rather confused by the results; once the traced process
93 stops, it cannot be made to continue except via
95 When a process has used this request and calls
97 or any of the routines built on it
100 it will stop before executing the first instruction of the new image.
101 Also, any setuid or setgid bits on the executable being executed will
103 .It Dv PT_READ_I , Dv PT_READ_D
104 These requests read a single
106 of data from the traced process's address space.
109 has allowed for machines with distinct address spaces for instruction
110 and data, which is why there are two requests: conceptually,
112 reads from the instruction space and
114 reads from the data space.
117 implementation, these two requests are completely identical.
120 argument specifies the address
121 (in the traced process's virtual address space)
122 at which the read is to be done.
123 This address does not have to meet any alignment constraints.
124 The value read is returned as the return value from
126 .It Dv PT_WRITE_I , Dv PT_WRITE_D
127 These requests parallel
131 except that they write rather than read.
134 argument supplies the value to be written.
136 This request allows reading and writing arbitrary amounts of data in
137 the traced process's address space.
140 argument specifies a pointer to a
141 .Vt "struct ptrace_io_desc" ,
142 which is defined as follows:
144 struct ptrace_io_desc {
145 int piod_op; /* I/O operation */
146 void *piod_offs; /* child offset */
147 void *piod_addr; /* parent offset */
148 size_t piod_len; /* request length */
152 * Operations in piod_op.
154 #define PIOD_READ_D 1 /* Read from D space */
155 #define PIOD_WRITE_D 2 /* Write to D space */
156 #define PIOD_READ_I 3 /* Read from I space */
157 #define PIOD_WRITE_I 4 /* Write to I space */
163 The actual number of bytes read or written is stored in
167 The traced process continues execution.
171 is an address specifying the place where execution is to be resumed
172 (a new value for the program counter),
174 .Po Vt caddr_t Pc Ns 1
175 to indicate that execution is to pick up where it left off.
179 provides a signal number to be delivered to the traced process as it
180 resumes execution, or 0 if no signal is to be sent.
182 The traced process is single stepped one instruction.
187 .Po Vt caddr_t Pc Ns 1 .
191 provides a signal number to be delivered to the traced process as it
192 resumes execution, or 0 if no signal is to be sent.
194 The traced process terminates, as if
198 given as the signal to be delivered.
200 This request allows a process to gain control of an otherwise
201 unrelated process and begin tracing it.
202 It does not need any cooperation from the to-be-traced process.
206 specifies the process ID of the to-be-traced process, and the other
207 two arguments are ignored.
208 This request requires that the target process must have the same real
209 UID as the tracing process, and that it must not be executing a setuid
210 or setgid executable.
211 (If the tracing process is running as root, these restrictions do not
213 The tracing process will see the newly-traced process stop and may
214 then control it as if it had been traced all along.
216 This request is like PT_CONTINUE, except that it does not allow
217 specifying an alternate place to continue execution, and after it
218 succeeds, the traced process is no longer traced and continues
221 This request reads the traced process's machine registers into the
230 This request is the converse of
232 it loads the traced process's machine registers from the
241 This request reads the traced process's floating-point registers into
251 This request is the converse of
253 it loads the traced process's floating-point registers from the
262 This request reads the traced process's debug registers into
272 This request is the converse of
274 it loads the traced process's debug registers from the
283 This request can be used to obtain information about the kernel thread,
284 also known as light-weight process, that caused the traced process to stop.
287 argument specifies a pointer to a
288 .Vt "struct ptrace_lwpinfo" ,
289 which is defined as follows:
291 struct ptrace_lwpinfo {
297 siginfo_t pl_siginfo;
298 char pl_tdname[MAXCOMLEN + 1];
305 argument is to be set to the size of the structure known to the caller.
306 This allows the structure to grow without affecting older programs.
309 .Vt "struct ptrace_lwpinfo"
310 have the following meaning:
311 .Bl -tag -width indent -compact
315 Event that caused the stop.
316 Currently defined events are
317 .Bl -tag -width indent -compact
321 Thread stopped due to the pending signal
324 Flags that specify additional details about observed stop.
325 Currently defined flags are:
326 .Bl -tag -width indent -compact
328 The thread stopped due to system call entry, right after the kernel is entered.
329 The debugger may examine syscall arguments that are stored in memory and
330 registers according to the ABI of the current process, and modify them,
333 The thread is stopped immediately before syscall is returning to the usermode.
334 The debugger may examine system call return values in the ABI-defined registers
339 is set, this flag may be additionally specified to inform that the
340 program being executed by debuggee process has been changed by successful
341 execution of a system call from the
348 .Vt "struct ptrace_lwpinfo"
349 contains valid information.
351 Indicates that the process is returning from a call to
353 that created a new child process.
354 The process identifier of the new process is available in the
357 .Vt "struct ptrace_lwpinfo" .
360 The current signal mask of the LWP
362 The current pending set of signals for the LWP.
363 Note that signals that are delivered to the process would not appear
364 on an LWP siglist until the thread is selected for delivery.
366 The siginfo that accompanies the signal pending.
374 The name of the thread.
376 The process identifier of the new child process.
385 This request returns the number of kernel threads associated with the
388 This request can be used to get the current thread list.
389 A pointer to an array of type
393 with the array size specified by
395 The return value from
397 is the count of array entries filled in.
399 This request will turn on single stepping of the specified process.
401 This request will turn off single stepping of the specified process.
403 This request will suspend the specified thread.
405 This request will resume the specified thread.
407 This request will trace the specified process on each system call entry.
409 This request will trace the specified process on each system call exit.
411 This request will trace the specified process
412 on each system call entry and exit.
414 This request controls tracing for new child processes of a traced process.
418 then new child processes will enable tracing and stop before executing their
422 is zero, then new child processes will execute without tracing enabled.
423 By default, tracing is not enabled for new child processes.
424 Child processes do not inherit this property.
425 The traced process will set the
427 flag upon exit from a system call that creates a new process.
429 This request returns the generation number or timestamp of the memory map of
430 the traced process as the return value from
432 This provides a low-cost way for the tracing process to determine if the
433 VM map changed since the last time this request was made.
435 This request is used to iterate over the entries of the VM map of the traced
439 argument specifies a pointer to a
440 .Vt "struct ptrace_vm_entry" ,
441 which is defined as follows:
443 struct ptrace_vm_entry {
457 The first entry is returned by setting
460 Subsequent entries are returned by leaving
462 unmodified from the value returned by previous requests.
465 field can be used to detect changes to the VM map while iterating over the
467 The tracing process can then take appropriate action, such as restarting.
470 to a non-zero value on entry, the pathname of the backing object is returned
471 in the buffer pointed to by
473 provided the entry is backed by a vnode.
476 field is updated with the actual length of the pathname (including the
477 terminating null character).
480 field is the offset within the backing object at which the range starts.
481 The range is located in the VM space at
492 Additionally, machine-specific requests can exist.
494 Some requests can cause
498 as a non-error value; to disambiguate,
500 can be set to 0 before the call and checked afterwards.
504 system call may fail if:
509 No process having the specified process ID exists.
514 A process attempted to use
521 was not one of the legal requests.
528 was neither 0 nor a legal signal number.
537 was attempted on a process with no valid register set.
538 (This is normally true only of system processes.)
541 was given an invalid value for
543 This can also be caused by changes to the VM map of the process.
549 was attempted on a process that was already being traced.
551 A request attempted to manipulate a process that was being traced by
552 some process other than the one making the request.
557 specified a process that was not stopped.
565 attempted to manipulate a process that was not being traced at all.
567 An attempt was made to use
569 on a process in violation of the requirements listed under
577 previously returned the last entry of the memory map.
578 No more entries exist.
580 .It Bq Er ENAMETOOLONG
584 cannot return the pathname of the backing object because the buffer is not big
587 holds the minimum buffer size required on return.
595 .Xr i386_clr_watch 3 ,
609 are not implemented for MIPS and ARM architectures.