Changeset View
Standalone View
lib/libc/sys/ptrace.2
.\" $FreeBSD$ | .\" $FreeBSD$ | |||||||||
.\" $NetBSD: ptrace.2,v 1.2 1995/02/27 12:35:37 cgd Exp $ | .\" $NetBSD: ptrace.2,v 1.2 1995/02/27 12:35:37 cgd Exp $ | |||||||||
.\" | .\" | |||||||||
.\" This file is in the public domain. | .\" This file is in the public domain. | |||||||||
.Dd July 15, 2019 | .Dd April 10, 2021 | |||||||||
.Dt PTRACE 2 | .Dt PTRACE 2 | |||||||||
.Os | .Os | |||||||||
.Sh NAME | .Sh NAME | |||||||||
.Nm ptrace | .Nm ptrace | |||||||||
.Nd process tracing and debugging | .Nd process tracing and debugging | |||||||||
.Sh LIBRARY | .Sh LIBRARY | |||||||||
.Lb libc | .Lb libc | |||||||||
.Sh SYNOPSIS | .Sh SYNOPSIS | |||||||||
▲ Show 20 Lines • Show All 788 Lines • ▼ Show 20 Lines | ||||||||||
.Va pve_start | .Va pve_start | |||||||||
and extends up to | and extends up to | |||||||||
.Va pve_end | .Va pve_end | |||||||||
(inclusive). | (inclusive). | |||||||||
.Pp | .Pp | |||||||||
The | The | |||||||||
.Fa data | .Fa data | |||||||||
argument is ignored. | argument is ignored. | |||||||||
.It Dv PT_COREDUMP | ||||||||||
This request creates a coredump for the stopped program. | ||||||||||
.Fa addr | ||||||||||
emaste: The
.Fa addr
argument... | ||||||||||
argument specifies a pointer to a | ||||||||||
.Vt "struct ptrace_coredump" , | ||||||||||
which is defined as follows: | ||||||||||
.Bd -literal | ||||||||||
struct ptrace_coredump { | ||||||||||
TODO; | ||||||||||
}; | ||||||||||
.Ed | ||||||||||
.Pp | ||||||||||
The size of | ||||||||||
.Vt "struct ptrace_coredump" | ||||||||||
must be passed in | ||||||||||
.Fa data . | ||||||||||
.El | .El | |||||||||
Done Inline ActionsShould we indicate what type(s) of file descriptors are permissible? emaste: Should we indicate what type(s) of file descriptors are permissible? | ||||||||||
.Sh ARM MACHINE-SPECIFIC REQUESTS | .Sh ARM MACHINE-SPECIFIC REQUESTS | |||||||||
.Bl -tag -width "Dv PT_SETVFPREGS" | .Bl -tag -width "Dv PT_SETVFPREGS" | |||||||||
Done Inline Actions
markj: | ||||||||||
.It Dv PT_GETVFPREGS | .It Dv PT_GETVFPREGS | |||||||||
Return the thread's | Return the thread's | |||||||||
.Dv VFP | .Dv VFP | |||||||||
machine state in the buffer pointed to by | machine state in the buffer pointed to by | |||||||||
.Fa addr . | .Fa addr . | |||||||||
.Pp | .Pp | |||||||||
Done Inline ActionsCan we clarify non-dumpable? emaste: Can we clarify non-dumpable?
Do we need a comment in mmap(2) alongside `MAP_NOCORE`? I assume… | ||||||||||
The | The | |||||||||
.Fa data | .Fa data | |||||||||
argument is ignored. | argument is ignored. | |||||||||
.It Dv PT_SETVFPREGS | .It Dv PT_SETVFPREGS | |||||||||
Set the thread's | Set the thread's | |||||||||
.Dv VFP | .Dv VFP | |||||||||
machine state from the buffer pointed to by | machine state from the buffer pointed to by | |||||||||
.Fa addr . | .Fa addr . | |||||||||
.Pp | .Pp | |||||||||
The | The | |||||||||
.Fa data | .Fa data | |||||||||
argument is ignored. | argument is ignored. | |||||||||
Done Inline ActionsMaybe "must already be stopped"? emaste: Maybe "must already be stopped"? | ||||||||||
.El | .El | |||||||||
.Sh x86 MACHINE-SPECIFIC REQUESTS | .Sh x86 MACHINE-SPECIFIC REQUESTS | |||||||||
.Bl -tag -width "Dv PT_GETXSTATE_INFO" | .Bl -tag -width "Dv PT_GETXSTATE_INFO" | |||||||||
.It Dv PT_GETXMMREGS | .It Dv PT_GETXMMREGS | |||||||||
Copy the XMM FPU state into the buffer pointed to by the | Copy the XMM FPU state into the buffer pointed to by the | |||||||||
argument | argument | |||||||||
.Fa addr . | .Fa addr . | |||||||||
Done Inline Actions
markj: | ||||||||||
The buffer has the same layout as the 32-bit save buffer for the | The buffer has the same layout as the 32-bit save buffer for the | |||||||||
machine instruction | machine instruction | |||||||||
.Dv FXSAVE . | .Dv FXSAVE . | |||||||||
Done Inline Actions
markj: | ||||||||||
.Pp | .Pp | |||||||||
This request is only valid for i386 programs, both on native 32-bit | This request is only valid for i386 programs, both on native 32-bit | |||||||||
systems and on amd64 kernels. | systems and on amd64 kernels. | |||||||||
Done Inline ActionsSo in some error cases this is not true. How does userspace know whether it needs to wait? markj: So in some error cases this is not true. How does userspace know whether it needs to wait? | ||||||||||
Done Inline ActionsI propose to not care about the difference, see updated man page and my other reply. kib: I propose to not care about the difference, see updated man page and my other reply. | ||||||||||
For 64-bit amd64 programs, the XMM state is reported as part of | For 64-bit amd64 programs, the XMM state is reported as part of | |||||||||
Done Inline Actions
markj: | ||||||||||
the FPU state returned by the | the FPU state returned by the | |||||||||
.Dv PT_GETFPREGS | .Dv PT_GETFPREGS | |||||||||
request. | request. | |||||||||
.Pp | .Pp | |||||||||
Done Inline Actions
markj: | ||||||||||
The | The | |||||||||
.Fa data | .Fa data | |||||||||
argument is ignored. | argument is ignored. | |||||||||
.It Dv PT_SETXMMREGS | .It Dv PT_SETXMMREGS | |||||||||
Load the XMM FPU state for the thread from the buffer pointed to | Load the XMM FPU state for the thread from the buffer pointed to | |||||||||
by the argument | by the argument | |||||||||
.Fa addr . | .Fa addr . | |||||||||
Done Inline ActionsI believe there is no race here if a thread was unsuspended: after ptrace(PT_COREDUMP) returns, the use of the proc lock in ptracestop() ensures that the new stop event is immediately visible to a waitpid(WNOHANG) caller. Is that correct? I am just concerned about waitpid(WNOHANG) returning a false negative, i.e., there is a new stop event to consume but waitpid(WNOHANG) did not consume it because the re-suspension happens asynchronously. markj: I believe there is no race here if a thread was unsuspended: after ptrace(PT_COREDUMP) returns… | ||||||||||
Done Inline ActionsThe waitpid(WNOHANG) should be executed atfer ptrace(PT_COREDUMP) returned. The unsuspended thread suspends itself, which generates the event by thread_suspend_switch()->thread_stopped()->childproc_stopped() before wakeup. So you are right that there is no race, but the main reason is that the event generation is in fact synchronous. kib: The waitpid(WNOHANG) should be executed atfer ptrace(PT_COREDUMP) returned. The unsuspended… | ||||||||||
Done Inline ActionsDoesn't the wakeup happen in ptrace_coredump(), before the thread_suspend_switch() call? markj: Doesn't the wakeup happen in ptrace_coredump(), before the thread_suspend_switch() call? | ||||||||||
Done Inline ActionsHm, yes. I think I will not change anything, because indeed the process lock is held. But the sleep/wakeup there can be changed to p->p_pptr wchan, and then wakeup in ptrace_coredump() is not needed. kib: Hm, yes. I think I will not change anything, because indeed the process lock is held. But the… | ||||||||||
The buffer has the same layout as the 32-bit load buffer for the | The buffer has the same layout as the 32-bit load buffer for the | |||||||||
machine instruction | machine instruction | |||||||||
.Dv FXRSTOR . | .Dv FXRSTOR . | |||||||||
.Pp | .Pp | |||||||||
As with | As with | |||||||||
.Dv PT_GETXMMREGS , | .Dv PT_GETXMMREGS , | |||||||||
this request is only valid for i386 programs. | this request is only valid for i386 programs. | |||||||||
.Pp | .Pp | |||||||||
▲ Show 20 Lines • Show All 308 Lines • Show Last 20 Lines |
The
.Fa addr
argument...