1*65525Spendrysaute procfs lyonnais 2*65525Spendry 3*65525Spendryprocfs supports two levels of directory. the filesystem root 4*65525Spendrydirectory contains a representation of the system process table. 5*65525Spendrythis consists of an entry for each active and zombie process, and 6*65525Spendryan additional entry "curproc" which always represents the process 7*65525Spendrymaking the lookup request. 8*65525Spendry 9*65525Spendryeach of the sub-directories contains several files. these files 10*65525Spendryare used to control and interrogate processes. the files implemented 11*65525Spendryare: 12*65525Spendry 13*65525Spendry file - xxx. the exec'ed file. 14*65525Spendry 15*65525Spendry status - r/o. returns process status. 16*65525Spendry 17*65525Spendry ctl - w/o. sends a control message to the process. 18*65525Spendry for example: 19*65525Spendry echo hup > /proc/curproc/note 20*65525Spendry will send a SIGHUP to the shell. 21*65525Spendry whereas 22*65525Spendry echo attach > /proc/1293/ctl 23*65525Spendry would set up process 1293 for debugging. 24*65525Spendry see below for more details. 25*65525Spendry 26*65525Spendry mem - r/w. virtual memory image of the process. 27*65525Spendry parts of the address space are readable 28*65525Spendry only if they exist in the target process. 29*65525Spendry a more reasonable alternative might be 30*65525Spendry to return zero pages instead of an error. 31*65525Spendry comments? 32*65525Spendry 33*65525Spendry note - w/o. writing a string here sends the 34*65525Spendry equivalent note to the process. 35*65525Spendry [ not implemented. ] 36*65525Spendry 37*65525Spendry notepg - w/o. the same as note, but sends to all 38*65525Spendry members of the process group. 39*65525Spendry [ not implemented. ] 40*65525Spendry 41*65525Spendry regs - r/w. process register set. this can be read 42*65525Spendry or written any time even if the process 43*65525Spendry is not stopped. since the bsd kernel 44*65525Spendry is single-processor, this implementation 45*65525Spendry will get the "right" register values. 46*65525Spendry a multi-proc kernel would need to do some 47*65525Spendry synchronisation. 48*65525Spendry 49*65525Spendrythis then looks like: 50*65525Spendry 51*65525Spendry% ls -li /proc 52*65525Spendrytotal 0 53*65525Spendry 9 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 0 54*65525Spendry 17 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 1 55*65525Spendry 89 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 10 56*65525Spendry 25 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 2 57*65525Spendry2065 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 257 58*65525Spendry2481 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 309 59*65525Spendry 265 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 32 60*65525Spendry3129 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 390 61*65525Spendry3209 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 400 62*65525Spendry3217 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 401 63*65525Spendry3273 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 408 64*65525Spendry 393 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 48 65*65525Spendry 409 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 50 66*65525Spendry 465 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 57 67*65525Spendry 481 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 59 68*65525Spendry 537 dr-xr-xr-x 2 root kmem 0 Sep 21 15:06 66 69*65525Spendry 545 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 67 70*65525Spendry 657 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 81 71*65525Spendry 665 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 82 72*65525Spendry 673 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 83 73*65525Spendry 681 dr-xr-xr-x 2 root wheel 0 Sep 21 15:06 84 74*65525Spendry3273 dr-xr-xr-x 2 jsp staff 0 Sep 21 15:06 curproc 75*65525Spendry% ls -li /proc/curproc 76*65525Spendrytotal 408 77*65525Spendry3341 --w------- 1 jsp staff 0 Sep 21 15:06 ctl 78*65525Spendry1554 -r-xr-xr-x 1 bin bin 90112 Mar 29 04:52 file 79*65525Spendry3339 -rw------- 1 jsp staff 118784 Sep 21 15:06 mem 80*65525Spendry3343 --w------- 1 jsp staff 0 Sep 21 15:06 note 81*65525Spendry3344 --w------- 1 jsp staff 0 Sep 21 15:06 notepg 82*65525Spendry3340 -rw------- 1 jsp staff 0 Sep 21 15:06 regs 83*65525Spendry3342 -r--r--r-- 1 jsp staff 0 Sep 21 15:06 status 84*65525Spendry% df /proc/curproc /proc/curproc/file 85*65525SpendryFilesystem 512-blocks Used Avail Capacity Mounted on 86*65525Spendryproc 2 2 0 100% /proc 87*65525Spendry/dev/wd0a 16186 13548 1018 93% / 88*65525Spendry% cat /proc/curproc/status 89*65525Spendrycat 446 439 400 81 12,0 ctty 748620684 270000 0 0 0 20000 nochan 11 20 20 20 0 21 117 90*65525Spendry 91*65525Spendry 92*65525Spendry 93*65525Spendrythe basic sequence of commands written to "ctl" would be 94*65525Spendry 95*65525Spendry attach - this stops the target process and 96*65525Spendry arranges for the sending process 97*65525Spendry to become the debug control process 98*65525Spendry wait - wait for the target process to come to 99*65525Spendry a steady state ready for debugging. 100*65525Spendry step - single step, with no signal delivery. 101*65525Spendry run - continue running, with no signal delivery, 102*65525Spendry until next trap or breakpoint. 103*65525Spendry <signame> - deliver signal <signame> and continue running. 104*65525Spendry detach - continue execution of the target process 105*65525Spendry and remove it from control by the debug process 106*65525Spendry 107*65525Spendryin a normal debugging environment, where the target is fork/exec'd by 108*65525Spendrythe debugger, the debugger should fork and the child should stop itself 109*65525Spendry(with a self-inflicted SIGSTOP). the parent should do a "wait" then an 110*65525Spendry"attach". as before, the child will hit a breakpoint on the first 111*65525Spendryinstruction in any newly exec'd image. 112*65525Spendry 113*65525Spendry$Id: README,v 3.1 1993/12/15 09:40:17 jsp Exp $ 114