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, stepping by the tracing
63 or an event in the traced process.
64 The tracing process may choose to intercept the signal, using it to
65 observe process behavior (such as
67 or forward the signal to the process if appropriate.
71 is the mechanism by which all this happens.
73 A traced process may report additional signal stops corresponding to
74 events in the traced process.
75 These additional signal stops are reported as
80 The tracing process can use the
82 request to determine which events are associated with a
87 Note that multiple events may be associated with a single signal.
88 For example, events indicated by the
93 flags are also reported as a system call exit event
95 The signal stop for a new child process enabled via
100 All other additional signal stops use
103 Each traced process has a tracing event mask.
104 An event in the traced process only reports a
105 signal stop if the corresponding flag is set in the tracing event mask.
106 The current set of tracing event flags include:
107 .Bl -tag -width ".Dv PTRACE_SYSCALL"
109 Report a stop for a successful invocation of
111 This event is indicated by the
116 .Vt "struct ptrace_lwpinfo" .
118 Report a stop on each system call entry.
119 This event is indicated by the
124 .Vt "struct ptrace_lwpinfo" .
126 Report a stop on each system call exit.
127 This event is indicated by the
132 .Vt "struct ptrace_lwpinfo" .
133 .It Dv PTRACE_SYSCALL
134 Report stops for both system call entry and exit.
136 This event flag controls tracing for new child processes of a traced process.
138 When this event flag is enabled,
139 new child processes will enable tracing and stop before executing their
141 The new child process will include the
146 .Vt "struct ptrace_lwpinfo" .
147 The traced process will report a stop that includes the
150 The process ID of the new child process will also be present in the
153 .Vt "struct ptrace_lwpinfo" .
154 Note that new child processes will be attached with the default
156 they do not inherit the event mask of the traced process.
158 When this event flag is not enabled,
159 new child processes will execute without tracing enabled.
161 This event flag controls tracing of LWP
163 creation and destruction.
164 When this event is enabled,
165 new LWPs will stop and report an event with
167 set before executing their first instruction,
168 and exiting LWPs will stop and report an event with
170 set before completing their termination.
172 Note that new processes do not report an event for the creation of their
174 and exiting processes do not report an event for the termination of the
178 The default tracing event mask when attaching to a process via
186 All other event flags are disabled.
190 argument specifies what operation is being performed; the meaning of
191 the rest of the arguments depends on the operation, but except for one
192 special case noted below, all
194 calls are made by the tracing process, and the
196 argument specifies the process ID of the traced process
197 or a corresponding thread ID.
204 This request is the only one used by the traced process; it declares
205 that the process expects to be traced by its parent.
206 All the other arguments are ignored.
207 (If the parent process does not expect to trace the child, it will
208 probably be rather confused by the results; once the traced process
209 stops, it cannot be made to continue except via
211 When a process has used this request and calls
213 or any of the routines built on it
216 it will stop before executing the first instruction of the new image.
217 Also, any setuid or setgid bits on the executable being executed will
219 If the child was created by
225 flag specified, the debugging events are reported to the parent
229 .It Dv PT_READ_I , Dv PT_READ_D
230 These requests read a single
232 of data from the traced process's address space.
235 has allowed for machines with distinct address spaces for instruction
236 and data, which is why there are two requests: conceptually,
238 reads from the instruction space and
240 reads from the data space.
243 implementation, these two requests are completely identical.
246 argument specifies the address
247 (in the traced process's virtual address space)
248 at which the read is to be done.
249 This address does not have to meet any alignment constraints.
250 The value read is returned as the return value from
252 .It Dv PT_WRITE_I , Dv PT_WRITE_D
253 These requests parallel
257 except that they write rather than read.
260 argument supplies the value to be written.
262 This request allows reading and writing arbitrary amounts of data in
263 the traced process's address space.
266 argument specifies a pointer to a
267 .Vt "struct ptrace_io_desc" ,
268 which is defined as follows:
270 struct ptrace_io_desc {
271 int piod_op; /* I/O operation */
272 void *piod_offs; /* child offset */
273 void *piod_addr; /* parent offset */
274 size_t piod_len; /* request length */
278 * Operations in piod_op.
280 #define PIOD_READ_D 1 /* Read from D space */
281 #define PIOD_WRITE_D 2 /* Write to D space */
282 #define PIOD_READ_I 3 /* Read from I space */
283 #define PIOD_WRITE_I 4 /* Write to I space */
289 The actual number of bytes read or written is stored in
293 The traced process continues execution.
297 is an address specifying the place where execution is to be resumed
298 (a new value for the program counter),
300 .Po Vt caddr_t Pc Ns 1
301 to indicate that execution is to pick up where it left off.
305 provides a signal number to be delivered to the traced process as it
306 resumes execution, or 0 if no signal is to be sent.
308 The traced process is single stepped one instruction.
313 .Po Vt caddr_t Pc Ns 1 .
317 provides a signal number to be delivered to the traced process as it
318 resumes execution, or 0 if no signal is to be sent.
320 The traced process terminates, as if
324 given as the signal to be delivered.
326 This request allows a process to gain control of an otherwise
327 unrelated process and begin tracing it.
328 It does not need any cooperation from the to-be-traced process.
332 specifies the process ID of the to-be-traced process, and the other
333 two arguments are ignored.
334 This request requires that the target process must have the same real
335 UID as the tracing process, and that it must not be executing a setuid
336 or setgid executable.
337 (If the tracing process is running as root, these restrictions do not
339 The tracing process will see the newly-traced process stop and may
340 then control it as if it had been traced all along.
342 This request is like PT_CONTINUE, except that it does not allow
343 specifying an alternate place to continue execution, and after it
344 succeeds, the traced process is no longer traced and continues
347 This request reads the traced process's machine registers into the
356 This request is the converse of
358 it loads the traced process's machine registers from the
367 This request reads the traced process's floating-point registers into
377 This request is the converse of
379 it loads the traced process's floating-point registers from the
388 This request reads the traced process's debug registers into
398 This request is the converse of
400 it loads the traced process's debug registers from the
409 This request can be used to obtain information about the kernel thread,
410 also known as light-weight process, that caused the traced process to stop.
413 argument specifies a pointer to a
414 .Vt "struct ptrace_lwpinfo" ,
415 which is defined as follows:
417 struct ptrace_lwpinfo {
423 siginfo_t pl_siginfo;
424 char pl_tdname[MAXCOMLEN + 1];
426 u_int pl_syscall_code;
427 u_int pl_syscall_narg;
433 argument is to be set to the size of the structure known to the caller.
434 This allows the structure to grow without affecting older programs.
437 .Vt "struct ptrace_lwpinfo"
438 have the following meaning:
439 .Bl -tag -width indent -compact
443 Event that caused the stop.
444 Currently defined events are
445 .Bl -tag -width indent -compact
449 Thread stopped due to the pending signal
452 Flags that specify additional details about observed stop.
453 Currently defined flags are:
454 .Bl -tag -width indent -compact
456 The thread stopped due to system call entry, right after the kernel is entered.
457 The debugger may examine syscall arguments that are stored in memory and
458 registers according to the ABI of the current process, and modify them,
461 The thread is stopped immediately before syscall is returning to the usermode.
462 The debugger may examine system call return values in the ABI-defined registers
467 is set, this flag may be additionally specified to inform that the
468 program being executed by debuggee process has been changed by successful
469 execution of a system call from the
476 .Vt "struct ptrace_lwpinfo"
477 contains valid information.
479 Indicates that the process is returning from a call to
481 that created a new child process.
482 The process identifier of the new process is available in the
485 .Vt "struct ptrace_lwpinfo" .
487 The flag is set for first event reported from a new child which is
488 automatically attached when
492 This flag is set for the first event reported from a new LWP when
495 It is reported along with
498 This flag is set for the last event reported by an exiting LWP when
501 Note that this event is not reported when the last LWP in a process exits.
502 The termination of the last thread is reported via a normal process exit
506 The current signal mask of the LWP
508 The current pending set of signals for the LWP.
509 Note that signals that are delivered to the process would not appear
510 on an LWP siglist until the thread is selected for delivery.
512 The siginfo that accompanies the signal pending.
520 The name of the thread.
522 The process identifier of the new child process.
530 The ABI-specific identifier of the current system call.
531 Note that for indirect system calls this field reports the indirected
540 The number of arguments passed to the current system call not counting
541 the system call identifier.
542 Note that for indirect system calls this field reports the arguments
543 passed to the indirected system call.
552 This request returns the number of kernel threads associated with the
555 This request can be used to get the current thread list.
556 A pointer to an array of type
560 with the array size specified by
562 The return value from
564 is the count of array entries filled in.
566 This request will turn on single stepping of the specified process.
568 This request will turn off single stepping of the specified process.
570 This request will suspend the specified thread.
572 This request will resume the specified thread.
574 This request will set the
576 event flag to trace all future system call entries and continue the process.
581 arguments are used the same as for
584 This request will set the
586 event flag to trace all future system call exits and continue the process.
591 arguments are used the same as for
594 This request will set the
596 event flag to trace all future system call entries and exits and continue
602 arguments are used the same as for
605 This request controls tracing for new child processes of a traced process.
610 is set in the traced process's event tracing mask.
615 is cleared from the traced process's event tracing mask.
617 This request controls tracing of LWP creation and destruction.
622 is set in the traced process's event tracing mask.
627 is cleared from the traced process's event tracing mask.
628 .It PT_GET_EVENT_MASK
629 This request reads the traced process's event tracing mask into the
630 integer pointed to by
632 The size of the integer must be passed in
634 .It PT_SET_EVENT_MASK
635 This request sets the traced process's event tracing mask from the
636 integer pointed to by
638 The size of the integer must be passed in
641 This request returns the generation number or timestamp of the memory map of
642 the traced process as the return value from
644 This provides a low-cost way for the tracing process to determine if the
645 VM map changed since the last time this request was made.
647 This request is used to iterate over the entries of the VM map of the traced
651 argument specifies a pointer to a
652 .Vt "struct ptrace_vm_entry" ,
653 which is defined as follows:
655 struct ptrace_vm_entry {
669 The first entry is returned by setting
672 Subsequent entries are returned by leaving
674 unmodified from the value returned by previous requests.
677 field can be used to detect changes to the VM map while iterating over the
679 The tracing process can then take appropriate action, such as restarting.
682 to a non-zero value on entry, the pathname of the backing object is returned
683 in the buffer pointed to by
685 provided the entry is backed by a vnode.
688 field is updated with the actual length of the pathname (including the
689 terminating null character).
692 field is the offset within the backing object at which the range starts.
693 The range is located in the VM space at
703 .Sh x86 MACHINE-SPECIFIC REQUESTS
704 .Bl -tag -width "Dv PT_GETXSTATE_INFO"
706 Copy the XMM FPU state into the buffer pointed to by the
709 The buffer has the same layout as the 32-bit save buffer for the
713 This request is only valid for i386 programs, both on native 32-bit
714 systems and on amd64 kernels.
715 For 64-bit amd64 programs, the XMM state is reported as part of
716 the FPU state returned by the
724 Load the XMM FPU state for the thread from the buffer pointed to
727 The buffer has the same layout as the 32-bit load buffer for the
733 this request is only valid for i386 programs.
738 .It Dv PT_GETXSTATE_INFO
739 Report which XSAVE FPU extensions are supported by the CPU
740 and allowed in userspace programs.
743 argument must point to a variable of type
744 .Vt struct ptrace_xstate_info ,
745 which contains the information on the request return.
746 .Vt struct ptrace_xstate_info
747 is defined as follows:
749 struct ptrace_xstate_info {
756 field is a bitmask of the currently enabled extensions.
757 The meaning of the bits is defined in the Intel and AMD
758 processor documentation.
761 field reports the length of the XSAVE area for storing the hardware
762 state for currently enabled extensions in the format defined by the x86
768 argument value must be equal to the size of the
769 .Vt struct ptrace_xstate_info .
771 Return the content of the XSAVE area for the thread.
774 argument points to the buffer where the content is copied, and the
776 argument specifies the size of the buffer.
777 The kernel copies out as much content as allowed by the buffer size.
778 The buffer layout is specified by the layout of the save area for the
782 Load the XSAVE state for the thread from the buffer specified by the
785 The buffer size is passed in the
788 The buffer must be at least as large as the
792 to allow the complete x87 FPU and XMM state load.
793 It must not be larger than the XSAVE state length, as reported by the
796 .Vt struct ptrace_xstate_info
798 .Dv PT_GETXSTATE_INFO
800 Layout of the buffer is identical to the layout of the load area for the
804 Return the value of the base used when doing segmented
805 memory addressing using the %fs segment register.
808 argument points to an
810 variable where the base value is stored.
818 request, but returns the base for the %gs segment register.
820 Set the base for the %fs segment register to the value pointed to
827 variable containing the new base.
835 request, but sets the base for the %gs segment register.
837 .Sh PowerPC MACHINE-SPECIFIC REQUESTS
838 .Bl -tag -width "Dv PT_SETVRREGS"
842 machine state in the buffer pointed to by
851 machine state from the buffer pointed to by
859 Additionally, other machine-specific requests can exist.
861 Some requests can cause
865 as a non-error value; to disambiguate,
867 can be set to 0 before the call and checked afterwards.
871 system call may fail if:
876 No process having the specified process ID exists.
881 A process attempted to use
888 was not one of the legal requests.
895 was neither 0 nor a legal signal number.
904 was attempted on a process with no valid register set.
905 (This is normally true only of system processes.)
908 was given an invalid value for
910 This can also be caused by changes to the VM map of the process.
916 was less than or equal to zero, or larger than the
918 structure known to the kernel.
922 provided to the x86-specific
923 .Dv PT_GETXSTATE_INFO
924 request was not equal to the size of the
925 .Vt struct ptrace_xstate_info .
929 provided to the x86-specific
931 request was less than the size of the x87 plus the XMM save area.
935 provided to the x86-specific
937 request was larger than returned in the
940 .Vt struct ptrace_xstate_info
942 .Dv PT_GETXSTATE_INFO
945 The base value, provided to the amd64-specific requests
949 pointed outside of the valid user address space.
950 This error will not occur in 32-bit programs.
956 was attempted on a process that was already being traced.
958 A request attempted to manipulate a process that was being traced by
959 some process other than the one making the request.
964 specified a process that was not stopped.
972 attempted to manipulate a process that was not being traced at all.
974 An attempt was made to use
976 on a process in violation of the requirements listed under
984 previously returned the last entry of the memory map.
985 No more entries exist.
987 .It Bq Er ENAMETOOLONG
991 cannot return the pathname of the backing object because the buffer is not big
994 holds the minimum buffer size required on return.
1002 .Xr i386_clr_watch 3 ,
1003 .Xr i386_set_watch 3
1007 function appeared in