114 lines
4.2 KiB
Plaintext
114 lines
4.2 KiB
Plaintext
saute procfs lyonnais
|
|
|
|
procfs supports two levels of directory. the filesystem root
|
|
directory contains a representation of the system process table.
|
|
this consists of an entry for each active and zombie process, and
|
|
an additional entry "curproc" which always represents the process
|
|
making the lookup request.
|
|
|
|
each of the sub-directories contains several files. these files
|
|
are used to control and interrogate processes. the files implemented
|
|
are:
|
|
|
|
file - xxx. the exec'ed file.
|
|
|
|
status - r/o. returns process status.
|
|
|
|
ctl - w/o. sends a control message to the process.
|
|
for example:
|
|
echo hup > /proc/curproc/note
|
|
will send a SIGHUP to the shell.
|
|
whereas
|
|
echo attach > /proc/1293/ctl
|
|
would set up process 1293 for debugging.
|
|
see below for more details.
|
|
|
|
mem - r/w. virtual memory image of the process.
|
|
parts of the address space are readable
|
|
only if they exist in the target process.
|
|
a more reasonable alternative might be
|
|
to return zero pages instead of an error.
|
|
comments?
|
|
|
|
note - w/o. writing a string here sends the
|
|
equivalent note to the process.
|
|
[ not implemented. ]
|
|
|
|
notepg - w/o. the same as note, but sends to all
|
|
members of the process group.
|
|
[ not implemented. ]
|
|
|
|
regs - r/w. process register set. this can be read
|
|
or written any time even if the process
|
|
is not stopped. since the bsd kernel
|
|
is single-processor, this implementation
|
|
will get the "right" register values.
|
|
a multi-proc kernel would need to do some
|
|
synchronisation.
|
|
|
|
this then looks like:
|
|
|
|
% ls -li /proc
|
|
total 0
|
|
9 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 0
|
|
17 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 1
|
|
89 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 10
|
|
25 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 2
|
|
2065 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 257
|
|
2481 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 309
|
|
265 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 32
|
|
3129 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 390
|
|
3209 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 400
|
|
3217 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 401
|
|
3273 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 408
|
|
393 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 48
|
|
409 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 50
|
|
465 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 57
|
|
481 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 59
|
|
537 dr-xr-xr-x 2 root kmem 0 Sep 21 15:06 66
|
|
545 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 67
|
|
657 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 81
|
|
665 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 82
|
|
673 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 83
|
|
681 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 84
|
|
3273 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 curproc
|
|
% ls -li /proc/curproc
|
|
total 408
|
|
3341 --w------- 1 jsp staff 0 Sep 21 15:06 ctl
|
|
1554 -r-xr-xr-x 1 bin bin 90112 Mar 29 04:52 file
|
|
3339 -rw------- 1 jsp staff 118784 Sep 21 15:06 mem
|
|
3343 --w------- 1 jsp staff 0 Sep 21 15:06 note
|
|
3344 --w------- 1 jsp staff 0 Sep 21 15:06 notepg
|
|
3340 -rw------- 1 jsp staff 0 Sep 21 15:06 regs
|
|
3342 -r--r--r-- 1 jsp staff 0 Sep 21 15:06 status
|
|
% df /proc/curproc /proc/curproc/file
|
|
Filesystem 512-blocks Used Avail Capacity Mounted on
|
|
proc 2 2 0 100% /proc
|
|
/dev/wd0a 16186 13548 1018 93% /
|
|
% cat /proc/curproc/status
|
|
cat 446 439 400 81 12,0 ctty 748620684 270000 0 0 0 20000 nochan 11 20 20 20 0 21 117
|
|
|
|
|
|
|
|
the basic sequence of commands written to "ctl" would be
|
|
|
|
attach - this stops the target process and
|
|
arranges for the sending process
|
|
to become the debug control process
|
|
wait - wait for the target process to come to
|
|
a steady state ready for debugging.
|
|
step - single step, with no signal delivery.
|
|
run - continue running, with no signal delivery,
|
|
until next trap or breakpoint.
|
|
<signame> - deliver signal <signame> and continue running.
|
|
detach - continue execution of the target process
|
|
and remove it from control by the debug process
|
|
|
|
in a normal debugging environment, where the target is fork/exec'd by
|
|
the debugger, the debugger should fork and the child should stop itself
|
|
(with a self-inflicted SIGSTOP). the parent should do a "wait" then an
|
|
"attach". as before, the child will hit a breakpoint on the first
|
|
instruction in any newly exec'd image.
|
|
|
|
$Id$
|