PROC(3) Library Functions Manual PROC(3)
proc - running processes
bind #p /proc
The proc device serves a two-level directory structure. The first
level contains numbered directories corresponding to pids of live pro-
cesses; each such directory contains a set of files representing the
The mem file contains the current memory image of the process. A read
or write at offset o, which must be a valid virtual address, accesses
bytes from address o up to the end of the memory segment containing o.
Kernel virtual memory, including the kernel stack for the process and
saved user registers (whose addresses are machine-dependent), can be
accessed through mem. Writes are permitted only while the process is
in the Stopped state and only to user addresses or registers.
The read-only proc file contains the kernel per-process structure. Its
main use is to recover the kernel stack and program counter for kernel
The read-only segment file contains a textual display of the memory
segments attached to the process. Each line has multiple fields: the
type of segment (Stack, Text, Data, Bss, etc.); one-letter flags such
as R for read-only, if any; starting virtual address, in hexadecimal;
ending virtual address, and reference count.
The read-only status file contains a string with eight fields, each
followed by a space. The fields are: the process name and user name,
each 27 characters left justified; the process state, 11 characters
left justified (see ps(1)); the six 11-character numbers also held in
the process's #c/cputime file, and the amount of memory used by the
process, except its stack, in units of 1024 bytes.
The text file is a pseudonym for the file from which the process was
executed; its main use is to recover the symbol table of the process.
The wait file may be read to recover Waitmsg records from the exiting
children of the process. If the process has no extant children, living
or exited, a read of wait will block. It is an error for a process to
attempt to read its own wait file when it has no children. When a
process's wait file is being read, the process will draw an error if it
attempts a wait system call; similarly, if a process is in a wait sys-
tem call, its wait file cannot be read by any process.
Textual messages written to the ctl file control the execution of the
process. Some require that the process is in a particular state and
return an error if it is not.
stop Suspend execution of the process, putting it in the Stopped
start Resume execution of a Stopped process.
waitstop Do not affect the process directly but, like all other mes-
sages ending with stop, block the process writing the ctl
file until the target process is in the Stopped state or
exits. Also like other stop control messages, if the target
process would receive a note while the message is pending, it
is instead stopped and the debugging process is resumed.
startstop Allow a Stopped process to resume, and then do a waitstop
hang Set a bit in the process so that, when it completes an
exec(2) system call, it will enter the Stopped state before
returning to user mode. This bit is inherited across a
nohang Clear the hang bit.
kill Kill the process the next time it crosses the user/kernel
Strings written to the note file will be posted as a note to the
process (see notify(2)). The note should be less than characters long;
the last character is reserved for a terminating NUL character. A read
of at least characters will retrieve the oldest note posted to the
process and prevent its delivery to the process. The notepg file is
similar, but the note will be delivered to all the processes in the
target process's note group (see fork(2)). However, if the process
doing the write is in the group, it will not receive the note. The
notepg file is write-only.
The textual noteid file may be read to recover an integer identifying
the note group of the process (see RFNOTEG in fork(2)). The file may
be written to cause the process to change to another note group, pro-
vided the group exists and is owned by the same user.
debugger(2), mach(2), cons(3)