![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to feel.ms CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / vol2 / pi|
Return to feel.ms CVS log | Up to [Research Unix] / researchv10dc / vol2 / pi |
1.1 ! root 1: .so ../ADM/mac ! 2: .XX pi 335 "The Feel of Pi" ! 3: ...\" Wed May 21 15:35:31 EDT 1986 ! 4: .ds p \f2pi\fP ! 5: .ds P \f2Pi\fP ! 6: .ds j \f2jim\fP ! 7: .ds J \f2Jim\fP ! 8: .TL ! 9: The Feel of Pi ! 10: .AU ! 11: T. A. Cargill ! 12: .AI ! 13: .MH ! 14: .AB ! 15: .PP ! 16: \*P is an interactive debugger for C and C++ on Eighth Edition ! 17: .UX ! 18: systems. ! 19: Its user interface uses multiple windows on a DMD 5620 terminal. ! 20: \*P does not feel like a debugger with a sequential command language, nor does it ! 21: feel like a debugger where commands from a bitmap display are translated into a ! 22: sequential command language. ! 23: In contrast, \*p's multiple windows display multiple active views of its multiple ! 24: subject processes, allowing the programmer to browse through a network of ! 25: information. ! 26: The programmer interactively explores a set of executing processes, ! 27: probing for insight with a tool that really helps. ! 28: .PP ! 29: Each window displays a specific view of a subject process in parallel with ! 30: the other windows. ! 31: The contents of pop-up menus are determined by context; ! 32: the current window and the line of text selected within it. ! 33: .PP ! 34: \*P is written in C++ and uses Eighth Edition's ! 35: .CW /proc ! 36: to access arbitrary live subject processes. ! 37: .AE ! 38: .SH ! 39: Introduction ! 40: .PP ! 41: \*P (Process Inspector) is an experiment in debugging with an interactive, bitmap ! 42: graphics user interface. ! 43: The debugging technology is conventional: breakpoints are planted in the subject ! 44: process so that the states the process moves through may be examined. ! 45: But the user interface is unconventional. ! 46: .PP ! 47: In a conventional debugger, the programmer inputs a sequence of commands that are ! 48: interpreted by the debugger. ! 49: The debugger responds with information about the subject process. ! 50: Several problems arise. ! 51: First, the debugger can usually accept only the subset of its commands ! 52: applicable to the debugger's current state. ! 53: For example, breakpoints can only be set in the current source file, or ! 54: expressions can only be evaluated in the current activation record. ! 55: Second, the debugger's output is passive and cannot be used to obtain ! 56: further information about, or other views of, the process. ! 57: For example, if a value is displayed by some command in an ! 58: inappropriate format, the programmer must re-issue the command, specifying another ! 59: format, or take the value and manipulate it elsewhere. ! 60: The effect is that any non-trivial debugging is accomplished by combining ! 61: the debugger with some of our oldest tools \- pencil and paper. ! 62: Third, a debugging command language must necessarily be very large, if it ! 63: is to be useful. ! 64: Generally, keyboard languages are complicated, and often cryptic. ! 65: .PP ! 66: The goal in writing \*p was to create a full-function interactive debugger with a ! 67: good user interface: ! 68: menu-driven, reactive, usable without a scratch pad or reference manual. ! 69: .SH ! 70: Interface Model ! 71: .PP ! 72: \*P's user interface assigns each view of a subject process to a ! 73: separate window. ! 74: Each window has its own menu of operations, appropriate to the view presented. ! 75: Within each window are lines of text providing details of the window's view. ! 76: Each line has its own menu of operations, appropriate to the information presented. ! 77: Interaction is driven by the programmer selecting operations from these menus. ! 78: In response to each operation, the debugger adds or removes windows, or lines, ! 79: or their menus. ! 80: A window or line may also choose to accept a line of input from the keyboard. ! 81: .PP ! 82: On the DMD 5620, a layer is subdivided into a set of scrolling, overlapping ! 83: windows. ! 84: The mechanics of the user interface are derived from \*j, a text editor by ! 85: Pike|reference(blit bstj) |reference(latest volume1). ! 86: There is a current window (with a heavy border), and within it a current ! 87: line (video-inverted). ! 88: Each button on the three-button mouse serves a specific role. ! 89: Button number 1 is for pointing. ! 90: If the cursor is outside the current window, button 1 selects a new current window. ! 91: If the cursor is inside and over a line of text, that line becomes current. ! 92: If inside and in the scroll zone, the window ! 93: scrolls to center the proportional scroll bar over the cursor. ! 94: Buttons 2 and 3 raise the pop-up menus for the current line and window, ! 95: respectively. ! 96: Menus also scroll and may have pop-up sub-menus, making large menus relatively ! 97: easy to use. ! 98: .SH ! 99: An Example ! 100: .PP ! 101: I will demonstrate \*p by examining the copy of \*j that I am ! 102: using to write this paper. ! 103: \*J is two processes, one in the host computer and one in the terminal. ! 104: I will work with its host process. ! 105: I create a new layer on my 5620's screen and simply invoke \*p: ! 106: .P1 ! 107: pi ! 108: .P2 ! 109: After about 20K bytes of user interface code has downloaded into the 5620, \*p's ! 110: cursor icon requests me to sweep a rectangle for a new window \- the ``Pi'' ! 111: window, the master window through which \*p may be bound dynamically to processes ! 112: and core dumps. ! 113: I now have one (almost empty) window in \*p's layer: ! 114: .MB binps ! 115: .LP ! 116: Selecting ! 117: .CW /bin/ps ' ` ! 118: from this window's menu runs the ! 119: .I ps ! 120: command and lists the output in the window, one process per line: ! 121: .MB jim ! 122: .LP ! 123: It shows me with a light load \- I am only editing. ! 124: To examine \*j, I point to process 10918 in this list and select ! 125: .CW open\ process ' ` ! 126: from its menu. ! 127: I am now requested to sweep a ``Process'' window. ! 128: The Process window has overall control of the process and can create windows ! 129: with more detailed views. ! 130: The process window shows the state of the process, and a callstack if ! 131: the process is stopped. ! 132: The state of process 10918 is: ! 133: .MB RUN1 ! 134: .LP ! 135: This is the usual state for \*j's host process ! 136: \- it is blocked reading from the terminal. ! 137: \*P polls the state of the process every second and updates the Process window ! 138: asynchronously with respect to the user and the subject process. ! 139: After some more editing the consumed processor time has increased.. ! 140: I raise the Process window's menu: ! 141: .MB srctext ! 142: .LP ! 143: .CW stop ' ` ! 144: stops the process asynchronously. ! 145: .CW run ' ` ! 146: restarts it. ! 147: .CW src\ text ' ` ! 148: creates windows for viewing source text. ! 149: .CW Globals ' ` ! 150: creates a window for evaluating expressions in global scope. ! 151: .CW RawMemory ' ` ! 152: creates a ``memory editor,'' in which uninterpreted memory cells may be viewed ! 153: and modified. ! 154: .CW Assembler ' ` ! 155: creates a window that disassembles memory and provides instruction level ! 156: operations. ! 157: .CW Signals ' ` ! 158: creates a window that monitors signals to the process. ! 159: .CW kill? ' ` ! 160: kills the process; the question mark calls for a confirming button hit. ! 161: .CW Journal ' ` ! 162: creates a window that records significant events in the process \- a trace. ! 163: .PP ! 164: First, I choose to look at some source text. ! 165: If there were a single source file, ! 166: .CW src\ text ' ` ! 167: would create a ``Source Text'' window for it. ! 168: \*J has several source files; so \*p asks me to sweep a ! 169: ``Source Files'' window that lists them: ! 170: .MB srcfiles ! 171: .LP ! 172: I point to ! 173: .CW pattern.c ! 174: and choose ! 175: .CW open\ source\ file ' ` ! 176: from its menu. ! 177: I sweep a Source Text window. ! 178: It fills with the first few lines of ! 179: .CW pattern.c . ! 180: I raise its menu: ! 181: .MB index ! 182: .LP ! 183: (I have not looked at this code before starting to write this example. ! 184: I believe I will find \*j's regular expression pattern matcher here. ! 185: I know no details of its implementation. ! 186: It is as if I were starting from scratch to find a bug in Pike's code.) ! 187: Moving the cursor over the arrow at the right of ! 188: .CW index\ by\ fcn ' ` ! 189: pops up a sub-menu that is a table of contents by function (with line number) of ! 190: .CW pattern.c : ! 191: .MB compile ! 192: It suggests, as I expected, that \*j compiles regular expressions into ! 193: a representation from which they can be interpreted efficiently. ! 194: To see some of this code, I select ! 195: .CW compile().......79 '. ` ! 196: This scrolls the window so that the line with the opening brace of ! 197: .CW compile() ! 198: is in the center: ! 199: .MB setbpt ! 200: .LP ! 201: To set a breakpoint, I point to a line of source text, say the opening brace, and ! 202: select ! 203: .CW set\ bpt ' ` ! 204: from its menu. ! 205: To indicate the breakpoint, ! 206: .CW >>> ' ` ! 207: appears at the beginning of the source line: ! 208: .MB gtgtgt ! 209: .LP ! 210: Note that the breakpoint was set while \*j executed asynchronously. ! 211: .PP ! 212: To force \*j to execute the breakpoint, I type (in \*j's layer) a search command ! 213: whose pattern matches a non-empty sequence of ! 214: .CW a ' ` ! 215: followed by a non-empty sequence of ! 216: .CW b ': ` ! 217: .CW /a+b+ . ! 218: When \*j hits the breakpoint, \*p asynchronously notices its change of state and ! 219: reports it in the Process window, along with as much of the callstack as fits ! 220: (here, only the deepest activation record): ! 221: .MB bpt ! 222: .LP ! 223: In the Source Text window, the breakpoint source line is ! 224: selected to show the current context. ! 225: To see more of the callstack I reshape the Process window, making it larger: ! 226: .MB callstack ! 227: .LP ! 228: To see the context from which ! 229: .CW compile() ! 230: was called, I select the ! 231: .CW commands(f=0xBCAC) ! 232: line from the callstack and choose ! 233: .CW show\ jim.c:368 ' ` ! 234: from its menu. ! 235: I am prompted to sweep another Source Text window, ! 236: .CW jim.c , ! 237: to see this context. ! 238: To catch the process before it calls ! 239: .CW execute() , ! 240: I change the selection from the line ! 241: .P1 ! 242: compile(p, TRUE); ! 243: .P2 ! 244: to the ! 245: .CW if ! 246: statement four lines below ! 247: and set a breakpoint: ! 248: .MB jimc ! 249: .LP ! 250: I then ! 251: .CW run ' ` ! 252: from the Source Text window's menu: ! 253: .MB run ! 254: .LP ! 255: .PP ! 256: When \*j reaches this breakpoint, I choose ! 257: .CW step\ into\ fcn ' ` ! 258: from the same menu to step the process into ! 259: .CW execute() . ! 260: (The other source stepping commands step ! 261: .I over ! 262: called functions.) ! 263: The source context for ! 264: .CW execute() ! 265: is back in the first source file, ! 266: .CW pattern.c . ! 267: .CW pattern.c 's ! 268: Source Text window moves to the front of the screen and highlights the ! 269: opening brace of ! 270: .CW execute() : ! 271: .MB step1stmt ! 272: .LP ! 273: It appears that the real work will be done by ! 274: .CW fexecute() . ! 275: I could set a breakpoint there, but I use ! 276: .CW step\ 1\ stmt ' ` ! 277: from the source window's menu a few times until I get to: ! 278: .P1 ! 279: return fexecute(f); ! 280: .P2 ! 281: and then use ! 282: .CW step\ into\ fcn ' ` ! 283: again. ! 284: The context shown from ! 285: .CW pattern.c ! 286: changes: ! 287: .MB fexec ! 288: .LP ! 289: .PP ! 290: .CW fexecute() ! 291: looks non-trivial. ! 292: Before going further, I would like to understand the data structure driving it. ! 293: I do not know what this data structure is. ! 294: Looking forward through the source text of ! 295: .CW fexecute() ! 296: I understand very little of the code. ! 297: But three lines do make sense: ! 298: .P1 ! 299: /* fast check for first char */ ! 300: if(startchar && *s!=startchar) ! 301: goto Continue; ! 302: .P2 ! 303: Surely, ! 304: .CW startchar ! 305: holds a literal character and ! 306: .CW s ! 307: is a pointer into a scanned string. ! 308: To test this I set a breakpoint on the ! 309: .CW if ! 310: and ! 311: .CW run '. ` ! 312: At the breakpoint I need the value of ! 313: .CW startchar . ! 314: Choosing ! 315: .CW open\ frame ' ` ! 316: from the source line's menu: ! 317: .MB openframe ! 318: .LP ! 319: creates a ``Frame'' window for the activation record of the function ! 320: corresponding to the source line. ! 321: A Frame window evaluates expressions with respect to its activation record. ! 322: The menu contains local variables, each flagged as an argument, an automatic or ! 323: a register: ! 324: .MB startchar ! 325: .LP ! 326: Choosing ! 327: .CW startchar ! 328: evaluates that expression: ! 329: .MB asciion ! 330: .LP ! 331: Is that an ! 332: .CW a '? ` ! 333: The value is in decimal because ! 334: .CW startchar ! 335: is declared ! 336: .CW int . ! 337: To override the default format, I select ! 338: .CW format ' ` ! 339: from the expression's menu, and ! 340: .CW ascii\ on ' ` ! 341: from the sub-menu. ! 342: The expression re-displays itself: ! 343: .MB a97 ! 344: .LP ! 345: .PP ! 346: The value of ! 347: .CW startchar ! 348: looks right and probably came from the data structure I am after. ! 349: Scrolling back a few lines in ! 350: .CW pattern.c ! 351: I find an assignment to ! 352: .CW startchar : ! 353: .MB assign ! 354: .LP ! 355: .CW fstart ! 356: may be the pointer I need, but it does not appear in ! 357: .CW fexecute() 's ! 358: menu. ! 359: It must be a global. ! 360: Rather than open the global expression evaluator window and look in its menu, ! 361: I enter the expression ! 362: .P1 ! 363: fstart ! 364: .P2 ! 365: from the keyboard, with ! 366: .CW fexecute() 's ! 367: Frame window selected as the target. ! 368: The Frame window now contains two expressions: ! 369: .in +.2i ! 370: .MB typeof ! 371: .LP ! 372: .in -.2i ! 373: What type is ! 374: .CW fstart ? ! 375: I can almost tell from its menu. ! 376: Most of the entries in an expression's menu are new expressions that may ! 377: be derived from it. ! 378: The ! 379: .CW $-> 's ! 380: tell me that I have a pointer to a structure. ! 381: (In the menu, and from the keyboard, ! 382: .CW $ ! 383: denotes the current expression.) ! 384: Choosing ! 385: .CW typeof\ $ ' ` ! 386: confirms it: ! 387: .in +.2i ! 388: .MB left ! 389: .in -.2i ! 390: .LP ! 391: Choosing ! 392: .CW $->left ', ` ! 393: followed by ! 394: .CW $->op ', ` ! 395: and ! 396: .CW $->right ' ` ! 397: yields: ! 398: .MB op ! 399: .LP ! 400: Reformatting ! 401: .CW fstart->op ! 402: in ASCII leaves: ! 403: .in +.2i ! 404: .MB star ! 405: .LP ! 406: .in -.2i ! 407: .LP ! 408: So here is some kind of tree, where an operator code ! 409: less than octal 200 is to match its own value in the scanned text. ! 410: The left sub-tree is empty; the right looks promising. ! 411: Dereferencing with ! 412: .CW *\ $ ' ` ! 413: yields: ! 414: .sp 0.5 ! 415: .in +.2i ! 416: .MB right ! 417: .in -.2i ! 418: The ! 419: .CW left ! 420: field of ! 421: .CW fstart->right ! 422: is equal to ! 423: .CW fstart ! 424: itself; maybe this is a doubly-linked list. ! 425: Applying ! 426: .CW $->right ' ` ! 427: to ! 428: .CW fstart->right , ! 429: I get: ! 430: .MB rr ! 431: .LP ! 432: I already know this, but applying ! 433: .CW *\ $ ' ` ! 434: produces (showing \*p's entire layer for the first time): ! 435: .MB thelast ! 436: .LP ! 437: Note that the value of the ! 438: .CW op ! 439: field for the current expression is displayed in ASCII as ! 440: .CW b '. ` ! 441: The ASCII format explicitly requested for that field earlier was saved in the ! 442: symbol table and is now the default. ! 443: The ! 444: .CW left ! 445: pointer is zero here. ! 446: It now looks as though ! 447: .CW left ! 448: points back to the beginning of the sub-pattern controlled by the ! 449: closure operator. ! 450: .PP ! 451: Let me stop here. ! 452: I have started to unravel the data structure and understand the program. ! 453: I hope this paper description conveys something of the feel of \*p. ! 454: .SH ! 455: Programmer Reaction ! 456: .PP ! 457: Most programmers take somewhere from a few hours to a few days to make the ! 458: transition from drowning in a sea of windows to considering \*p an indispensable ! 459: tool. ! 460: At the outset, they do not expect dynamic binding to subject processes and ! 461: cannot see why there are so many windows. ! 462: Invoking a debugger without specifying a dump or program is a foreign notion. ! 463: Expectations of a debugger are very low: ``I only want the value of ! 464: .I x ! 465: when ! 466: .I f() ! 467: is called \- why all the windows?'' ! 468: With increased confidence and ambition they use \*p with more sophistication. ! 469: Styles vary considerably. ! 470: Each programmer uses idiosyncratic sizes, shapes and placements of windows, ! 471: especially when debugging multiple processes. ! 472: Some prefer to enter most of their expressions from the keyboard, others ! 473: never touch it. ! 474: .PP ! 475: There are two main problems. ! 476: First, binding \*p to subject processes is too complicated for novices. ! 477: Experts demand many special facilities, which have been allowed to complicate ! 478: what the novice encounters. ! 479: Second, demand for programmable debugging is growing among the expert users. ! 480: Programmability was excluded from \*p in order to concentrate on ! 481: interactive behavior. ! 482: \*P does have ``spy'' expressions, which re-display themselves if their values ! 483: change, and conditional breakpoints, but it is not programmable, say, to ! 484: step 10 instructions after encountering a breakpoint. ! 485: It is now time to think about how programmability and interaction can be combined. ! 486: .SH ! 487: Asynchronous Multiple Processes ! 488: .PP ! 489: An arbitrary set of processes may be examined simultaneously. ! 490: For each subject process there is an independent network of windows. ! 491: Since all the windows are in a flat space on the screen, each successive action ! 492: from the programmer may be in an any window, associated with an any ! 493: process. ! 494: Events in the set of subject processes are reported as they occur. ! 495: For example, the programmer might step source statements alternately ! 496: between a pair of processes while watching the changing values of ! 497: spy expressions in a third process. ! 498: This simplifies debugging situations that were difficult or impossible ! 499: in the past. ! 500: For example, it becomes straightforward to ! 501: (i) compare the behavior of two similar programs; ! 502: (ii) compare the effects of different inputs on a single program; ! 503: (iii) observe the interaction between related processes, say child and parent. ! 504: .SH ! 505: Implementation ! 506: .PP ! 507: \*P depends on the Research ! 508: .UX 's ! 509: .CW /proc |reference(killian processes)|reference(latest volume1), ! 510: and object-oriented programming in C++|reference(cplusplus). ! 511: .PP ! 512: .CW /proc ! 513: permits \*p to bind itself dynamically to any processes, and execute ! 514: asynchronously with them. ! 515: For each process, \*p can tell the kernel how to handle an ! 516: .I exec() ! 517: by the process and signals received from other processes. ! 518: A breakpoint in code executed by a child of a subject process suspends the child ! 519: so that it may be opened and examined. ! 520: Code sharing is managed transparently by ! 521: .CW /proc . ! 522: .PP ! 523: The browsing and asynchrony are driven by object-oriented programming in C++. ! 524: A large host C++ program communicates with a small 5620 C program. ! 525: Everything the programmer can identify on the screen is a C++ object, an ! 526: instance of a class. ! 527: The host program binds an object identifier (which can be thought ! 528: of as a host address) and a menu of operations ! 529: to each window and each line of text as it describes them to the terminal. ! 530: When the programmer selects an operation from a menu associated with an object's ! 531: image, the terminal sends back a remote invocation of one of the object's member ! 532: functions. ! 533: Generally, executing this function creates, changes or removes host objects and ! 534: their images in the terminal. ! 535: Host-terminal communication is asynchronous; the programmer need not wait ! 536: for results to appear on the screen before issuing another operation. ! 537: There is no ambiguity in this ``mouse-ahead''; the identity of the object ! 538: on which a menu operates is frozen when the menu is raised. ! 539: A crude object registration scheme in the host detects (with high probability) ! 540: and ignores operations for objects that have been destroyed. ! 541: .SH ! 542: Conclusion ! 543: .PP ! 544: \*P's easy access to information about arbitrary processes ! 545: has made programmers more sophisticated in their debugging practices. ! 546: Programmers working with large programs written by others are happier. ! 547: Programmers who would not normally read assembly code can sometimes spot ! 548: code generation bugs in the compiler. ! 549: Programmers with families of interacting processes have a handle on them. ! 550: In general, programmers understand their programs better. ! 551: .SH ! 552: References ! 553: .LP ! 554: |reference_placement ! 555: .BP ! 556: photo page ! 557: .BP ! 558: divider with title ! 559: .sp ! 560: .ce ! 561: Supporting Tools and Languages
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.