Download A debugger for SAIL - The Stanford University InfoLab

Stanford Artificial Intelligence Laboratory
Memo AIM-270
Computer Science Department
Report No. STAN-B-75-523
A debugger for SAIL
bY
John F. Reiser
Research sponsored by
Advanced Research Projects Agency
ARPA Order No. 2494
and
National Science Foundation
October 1975
. Stanford Artificial Intelligence Laboratory
Memo AIM-270
October 1975
Computer Science Department
Report No. STAN-B-75-523
BAIL -- A debugger for SAIL
bY
John F. Reiser
ABSTRACT
BAIL is a debugging aid for SAIL programs, where SAIL is an extended dialect of ALGOL60
which runs on the PDP-10 computer. BAIL consists of a breakpoint package and an expression
interpreter which allow the user to stop his program at selected points, examine and change the
values of variables, and evaluate general SAIL expressions. In addition, BAIL can display
text from the source file corresponding to the current location in the program. In may respects
BAIL is like DDT or RAID, except that BAIL is oriented towards SAIL and k n o w s a b o u t
w
SAIL data types, primitive operations, a n d procedure implementation.
The work retorted here was funded in- part blp a National Science Foundation graduate
fellowship. Computer facilities provided by Stanford University under the Advanced Research
Projects Agency ARPA Contract DAHCI5-73-C-0435, and by Institute for Mathematical Studies
in the Social Sciences at Stanford
The views and conclusions contained in this document are those of the author(s) and should not be
interpreted as necessarily representing the oficial policies, either expressed or implied, of Stanford
University, ARPA, NSF, y the U. S. Government.
Reproduced in the U.S.A. Available from the National Technical Information Service, Springfield,
Virginia 22151.
.
TABLE OF CONTENTS
.BAIL - - A debugger for SAIL
.TABLE
OF CONTENTS
PAGE
SECTION
.3
4
INTRODUCTION
1
EXAMPLES
4
COMPILE-TIME ACTION
13
RUN-TIME’ ACTION
15
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
15
16
16
16
17
17
17
17
18
18
18
18
18
19
19
19
19
20
Debugging Requests
ARGS
BREAI(
DDT
HELP
SETLEX
SHOW
3 TEXT
TRACE
TRAPS
UNBREAK
’’
UNTRACE
! ! G O
!!GSTEP ’
!!STEP
STRING TYPEOUT
BAIL and DDT ‘
WARNINGS
RESOURCES USED
21
CURRENT STATUS
22
’ .1
’ INTRODUCTION
BAIL -- A debugger for SAIL
SECTION 1
*
c
INTRODUCTION
The ideal way to debug a computer program is to write it correctly in the first place
and not debug it at all. Experience has shown, however, that most programs of
moderate size contain errors, and that debugging is a significant part of software
product ion. BAIL is a tool which is designed to be useful for interactive debugging
of programs written in SAIL [4]! a high-level ALGOL-based language for Digital
Equipment Corporation (DEC) PDP-10 computers.
In the very early days of computing, debugging was done at the console of the
The programmer manipulated switches, observed lights, and had coteplete
computer.
control of the whole machine. The programmer could examine and change any location
in memory and could start, stop, and single-step the processor. Console debugging
soon became uneconomical on medium Ovid large-scale machines. It is stitl used on
minicomputers. This ‘type of debugging i ; at t ha machine-language level; the lights and
switches ars direst representatiofjs of bit!. inside %s machine.
Debugging moved to the assembly language leve9 *ith the development of interactive
time-sharing systems in the early 1960’s.
The programmer typed commands at a
terminal, and a collection of special subroutines interpreted the commands so that the
effect was similar to working at the console of the machine. Instead of communicating
in bits, the programmer and subroutines used character strings in the format of octal
and decimal integers, text, symbolic machine instructions, and symbolic addresses.
One of the most important features of the debugging routines was the ability to
suspend the execution of the program being debugged, enter the debugging
routines, communicate with the programmer, resume execution, and make the whole
process invisible to the program being debugged. This process became known as
breakpointing; the location where the main program was stopped is a breakpoint, and
the debugging routines are called a breakpoint package. The premier example of a
symbolic debugging package is DDT [l], developed for use on the DEC PDP-1 and
subsequently extended for use on the PDP-6 and PDP-10. DDT and its derivatives
are still among the most powerful tools for debugging assembly language programs.
BAIL is a high&level breakpoint package for use with SAIL programs. (Swinehart [a] and
Satterthwaite [2] c o n t a i n descriptions of other high-level debugging syst ems.)
Communication between the programmer and BAIL is in character strings which are the
names and values of SAIL objects. BAIL reads general SAIL expressions typed by
the programmer, evaluates them in the context of the place in the program where
execution was suspended, and prints the resulting value in an appropriate format. The
evaluation and printing are performed just as if the programmer had inserted an
extra statement into the original program at the point where execution was
suspended. BAIL also provides a way to talk about the program, to answer the
-
1
BAIL -- A debugger for SAIL
questions “Where was execution suspended?“, “By what chain of procedure calls
did execution proceed to that point?“, and “What is the text of the program?”
In order to perform these functions, BAIL must have some information about the
p r o g r a m b e i n g d e b u g g e d . The SAIL compiler will produce this information if the
program is compiled with an appropriate value supplied for the /B switch. (See the
technical portion of the manual for the exact meaning of the various switch values.)
ln these examples the compiler produces two files. File PROG.REL contains the
relocatable code and loader instructions, and file PROGSM 1 contains the information for
T h e PROGSM 1 information consists of the name, type, and
accessing
BAIL.
information for each variable and procedure, the location of the beginning and end
of each statement, and a description of the block structure.
The code for BAIL itself is loaded automatically when the program is loaded. In order
for the added Information and code to be of any use, it must be possible to give
control to BAIL at the appropriate time. An explicit call to BAIL is possible by
declaring EXTERNAL PROCEDURE BAIL; in the program and using the procedure call
BAIL;. This works well if it can be predicted in advance where BAlLing might be helpful,
Runtime errors, such as subscript overflow or CASE index errors, are not as predictable;
but responding “B” to the SAIL error handler will activate BAIL. interrupting the
program while it is running (to investigate a possible infinite loop, for example) can be
achieved under the TENEX operating system by typing control-B. On a DEC TOPS-10
operating system, first return to monitor mode by typing one or more cant rol-C’s, then
act ivat e BAIL by typing DD<cr>.
BAIL performs some initialization the first time it is entered. The information in the
.SM 1 file(s) is collected and processed into a file PROG.BAi. This new file reflects ail
of the information from the .SMl files of any separately-compiled programs, and
the relocation performed by the loader. If the core image was SAVEd or SSAVEd then
in subsequent runs BAIL will use the .BAl file and bypass much of the initialization.
BAIL prompts the programmer for input by typing a number and a colon. The number
indicates how many times BAIL has been entered but not yet exited, and thus is the
recursion depth inside BAIL. Input to BAIL can be edited using the standard SAIL
input-editing characters for the particular operating system under which the program
is running. [BAIL requests input via INCHWL on DEC TOPS-10 systems and via INTTY on
TENEX systems.] input is terminated whenever the editor act ivat es, string quotation
marks balance, and the last character is a semicolon; otherwise input lines are
concatenated into one string before being processed further.
The programmer may ask BAIL to evaluate any SAIL expression or procedure call
whose evaluation would be legal at the point at which execution of the program being
debugged was suspended (except that expressions involving AND, OR, IF-THENELSE, and CASE are not allowed.) BAIL evaluates the expression, prints the
resulting value in an appropriate format, and requests further input.
Declared inside BAIL are several procedures whose values or side effects are useful
P
BAIL -- A debugger for SAIL.
INTRODUCTION
in the debugging process. These procedures handle the insertion and deletion of
breakpoints, display t he static and dynamic scope of the current breakpoint, display
s e l e c t e d s t a t e m e n t s f r o m t h e s o u r c e p r o g r a m , a l l o w e s c a p e t o a n assemblylanguage debugging program, and cause resumption of the suspended main
program. These procedures are described in the technical portion of the manual.
The following examples illustrate many of the features available in BAIL. Text was
. recorded from an actual session on the computer.
/
n 1.
.A.
BAIL -- A debugger for SAIL
EXAMPLES
’ SECTION 2
EXAMPLES
This is a test program, run on TENEX.
@TYPE TESTLSAI
; 1 <REISER>TESTl.SAI;l
SAT 10-MAY-75 2:37PM
PAGE 1
BEGIN “TEST”
EXTERNAL PROCEDURE BAIL:
INTEGER I, J,K;
STRING A,B,C:
R E A L X,Y;Z;
INTEGER ARRAY fOO[0:151; STRING .ARRAY STRARR t1:5,2:63 ;
INTEGER I TEMVAR DAY; I TEMVAR CID;
I NTEGER PROCEDURE ADD ( INTEGER I , J) ; BEG1 N “ADD”
DUTSTR ( ”
HI. GLAD YOU STOPPED BY. “1:; RETURN (I +J) EtiD “ADD”;
RECURS I VE I NTEGER PROCEDURE FACT 1 INTEGER NJ : BEG1 N “FACT”
RETURN (IF N LEQ 1 THEN 1 ELSE N*FACT (N-11 1 END “FACT”;
S I MPLE PROCEDURE S I MPROC (REFERENCE I NTEGER MI ; BEG I N “SBEG”
ADD (M, M+32) END “SBEG”:
FOR I+0 STEP 1 UNTIL 15 DO FOOLIl+ItI;
FOR I+1 STEP 1 UNTIL 5 DO
FOR Jc2 STEP 1 UNTIL 6 DO
STRARR [I, J1+64+8ad+J;
1+4; J+6; K+ll2;
’ A+“BIG D E A L ” ; B+“QED”; W’THE L A S T P I C A S S O ” ; ’
X + 3 . 1 4 1 5 3 2 6 5 ; Y+0; 2~23. ;
BAIL;
ADD(7,45);
S I M P R O C (J) ;
USERERR(B,l,“THIS IS A TEST”);
,1
END ” TEST” ;
?L
4
EXAMPLES
BAIL -- A debugger for SAIL
Compile and load with BAIL.
&AIL. SAV; 10
TENEX SAIL 8.1 4-4-75 (? FOR HELP)
*TEST&+
wd27B
>k*
TESTl.SAI;l 1
BWDO;GCOPIPILATION.
LOADER 6+3K CORE
EXECUTION
Save the core image for later use.
&SAVE ( P A G E S F R O M ) 0 (TO) 577 (ON) TEST1 [NEW F I L E 1
[CONF I RR3
Start the program.
&TART
BAIL VER, l&MAY-75 .
TESTl.SM1;2
TESTl.SAI:l
*
End of BAIL initialization.
BAIL identifies itself and the files involved.
1: 45;
The “1:” is BAIL’s prompt. it indicates the level of
recursive invocations of BAIL and the fact that BAIL
is awaiting input.
45
1: 7.089;
7.083000
1: "SOME RANDOM STRING”;
"SOME RANDOM STRING"
1:‘275;
189
_
1: TRUE,F ALS$/WlLL;
-1
0
See how constants are entered and printed. The
“45;<cr>” is typed by the user, and the next l i n e
“45” is BAIL’s reply.
An octal constant; all printout is decimal.
Symbolic constants More than one expression
requested
BAIL -- A debugger for SAIL
1: I;
1:J4X*
ii’
1: I+46;
46
1: I;
46
EXAMPLES
. Variables,
assignment
1
3.141593
Relational operators; remember 0 is FALSE.
1: rq;
’ 0
1:J CEQ J;
-1
I:90 LAND '17;
2
An undeclared identifier
1: XYZ;
UNKNOWN ID: XYZ
Usable as a desk calculator
1:45:1:(89.4-53.06);
1635.300
1: X+J;
9.141593
Procedure call
1: AD D(3,4);
HI b GLAD YOU STOPPED BY.
7
l:ADD(3);
Argument list checking
ADD TAKES 2 ARGUMENTS, : ADD{31
1: FOO;
<ARRAY> E 0: 151
Arrays. Array name only gives dimension and
subscript bounds information.
l8 FP60f41;
1: Fff / 5 FOR 31;
36
49
1: STRARR;
-
Substring notation has been extended to cover array
element 8.
6
BAIL -- A debugger for SAIL
. Array accesses are interpreted
1: FOOf 351;
SUBSCRIPTIkG ERROR.
l:A;
.
"BIG DEAL"
1 : LENGTH(A); ’
e
8
1: I;
46
1: LOCATIONU );
718
1 : M6~MORY~718]+64; ’
EXAMPLES
INDEX
1
VALUE
35
MIN
0.
MAX
15
:
FOOt351
;
LENGTH, LOCATION, and MEMORY
1: I;
64
1: A/2 TO INF];
'I G DEAL"
1: W,,TO 41;
Type& must be terminated by a semicolon
l:B
;
Subst ringing +
"QED "
1: TRACE(“FACT”);
Tracing of procedure entry and exit
1: FACT(a);
ENTERING FACT 4
ENTERING FACT 3
ENTERING FACT 2
ENTERING FACT 1
EXITING FACT- 1
EXITING FACT- 2
EXITING FACT- 6
EX;;ING F A C T = 2 4
1: UNTRACE(“FACT”);
7
EXAMPLES
BAIL -- A debugger for SAIL
.
1: FACT(S);
120
Breakpoint ing
1: BREAWADD”);
1: ADD(3,4);
Now one level deeper in BAIL recursion. ARGS
prints the arguments list.
2: ARCS;
,3
4
Parameter names evaluate just like variables,
2:x;
3
2:J;
4
2s;
1
1
2
To exit from one level of BAIL
2:!!CO;
HI. GLAD YOU STOPPED BY.
7
The message is from ADD itself; the value 7 is from
BAIL.
Leave anot her level of BAIL.
l:!!CO;
And come back again. Where are we?
1: TEXT;
St at ic block structure
\;;;;A' SCOPE, TOP DOWN:
TEST
ADD
D y n a m i c p r o c e d u r e ,invocations. The #4 m e a n s
coordinate number 4,
;;;;;I$ SCOPE, fl;;;TRECENT FIRST:
ADD
#4
#24
TEST
SIMPROC (J) ;
I N T E G E R PROCEbURE ADDiINTEGER 1,J); BEG1
ADD(7,45);
:
USERERR(B,l,"
1: ARCS;
-
8
.
EXAMPLES
BAIL -- A debugger for SAIL
7
45
1: UNBREAK(“ADD”);
Remove the breakpoint.
1: l!CO;
Output from other calls in the program
HI. GLAD YOU STOPPED BY.
HI. GLAD YOU STOPPED BY.
THIS IS A TEST
CALLED FROM 642124 LAST SAIL CALL AT 400303
?B
Entry to BAIL from the error handler
1: TEXT;
LEXICAL SCOPE, TOP DOWNI
$RUN%
DYNAMIC SCOPE, R;;;TRECENT FIRST:
ROUT I NE
‘642124 X%X FILE NOT VIEWABLE
SIMPLE.
USERERR(B,l,“THIS IS A TEST”);
#26
TEsT
END “T
1: I;
UNKNOWN ID: I
I
1: SETLEXW;
The static scope needs to be set back one on the
dynamic chain.
‘iikm&;AL SCOPE, TOP DOWN:.
TEST
1: I;
64
1: c;
” THE LAST PI CASSO”
1: !!CO;
END OF SAIL EXECUTION.
9
BAIL -- A debu,gger for SAIL
EXAMPLES
Leap and records, DEC TOPS- 10 system.
. TYPE TEST2SAI
BAIL t
! PDL, 10 PNAMESj
L I S T L ; S E T S,Sl,S2,S3,S4,S5:
INTEGER ITEM SUNDAY; ITEM MONDAY,TUESDAY,WEDNESDAY ,THURSDAY,FRIOAY,
SATURDAY:
I NT E G ER ITEMVAR DAY; mhvm QQ;
ITEMVAR ARRAY Pt1:101;
RECORO!CLASS CELL (RECORD!POINTER(CELLI ,CAR,CORI;
RECORD!POINTER(CELLI CXJY:
CXcNEW!RECORD(CELLI;
CYtNEW!RECORO(CELLI;
CELL:CARICXlcNULL!RECORO; CELL:CDR[CXlcNULL!RECORD;
CELL:CAR KY1 cCX; CELLzCDR[CYl+NULL!RECORO;
.
P[ll cSUNOAY; P~21dlONDAY;
L+{ 1SUNDAYII; DATUM(SUNDAYI+B; DAYtSUNDAY: Q & M O N D A Y ; St(QQ);
Slt~SUNDAY,MONDAY,TUESDAY,WEONESDAY,THURSOAY~FRIDAY,SATURDAY~;
S2t~MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIOAY1;
S3c~MONDAY,WEONESDAY,FRIDAY~;
S4dSATURDAY,SUNDAYI;
,
S5dSUNDAY,FR I DAY);
FOREACH DAY SUCH THAT DAY IN Sl DO MAKE DAY XOR SUNDAY EQV SATURDAY;
.
BAIL:
USERERR(B,l,"THIS IS A TEST");
END "TEST":
EXIT
tC
. EXECUTE TEST2SAI(27B,)
SAIL: TEST2 1
LOADING
LOADER 15K CORE.
25K MAX 153, WORDS FREE
EXECUTION
BAIL VER. 10-MAY-75
TEST2. SMl
TEST2.SAI
END OF BAIL INITIALIZATION.
1: L;
(MJbiDAYI1
10
EXAMPLES
BAIL -- A debugger for SAIL
1:Sb;
{SUNDAY, SATURDAY)
1:s;
.
(SUNDAY, FRIDAY) '
1: S4 UNION SS;
{SUNDAY, FRIDAY, SATURDAY)
1: FRIDAY IN S4;.
0
1: S2 LEQ S2;
-1
1: DAY;
SATURDAY
.
1: DATUM(DAY);
0
1:cx;
CELL.9231
1: CELL:CARfCX];
NULL!RECORD
1: CELL:CAR/ CY j;
CELL.9231
1: SUNDAY ASSOC SATURDAY;
(SUNDAY)
’
1 : SUNDAY EQV SATURDAY;
(SUNDAY, MONDAY, TUESDAY, UEDNESDAY, THURSOAY, FRIDAY, SATURDAY)
1: SUNDAY XOR SATURDAY;
PHI
1: SUNDAY EQi SUNDAY;
PHI
1:x
’
11
BAIL i- A debugger for SAIL
EXAMPLES
c
I
I;
, .
QTESTI.SAV;I
Go back to the earlier example
Initialization uses file created last time.
B A I L ver. 10-May-75 using TESTl.BAI
End of BAIL initialization.
1: OPENFILE(NULL,“W”);
TODAY.TMP
S w i t c h /27B a t c o m p i l e - t i m e m a k e s SAIL
predeclared runtime routines known to BAIL,
4
1 :,OUT(4,“Tff IS Is A TEMPORARY FILE CREATED WHILE IN BAIL.“);
1: CFILE(4);
1: O-dENFILE(“” “RC?
TODAY.TMP [oiD V;RSIONI
l:$:NI(I 200 "Z")*
'1~~16 rg A TEMPORARY F IL E CREATED WHILE
ODTIMGl,-I); *
"SATURDAY, HAY 10, 1975 17:19:29”
1 :
. -
l:?
I N
BAILS
Quickie review of BAIL capabilities
EXPRESS ION;
PROCEOURE!CALL:
TRACE ("PROCEDURE");
UNTRACEV'PROCEDURE");
BREAKV'PROCEDURE, BLOCK, OR LABEL"):
~~;EV&EAK("PROCEDURE, BLOCK, OR LABEL"):
SETL~X(LEYEL);
TEXT:
ARGS;
HELP:
DDT;
?
1:x
End of the examples.
12
=, r
BAIL -- A debugger for SAIL
COMPILE-TIME ACTION
’
.-
SECTION 3
.
-
COMPILE-TIME ACTION
The principal result of activating BAIL at compile-time is the generation of a file of
information about the source program for use by the run-time interpreter, This file has
the same name as the .REL file produced by the compilation, except that the extension is
,SM 1. If requested, BAIL will also generate some additional code for SIMPLE procedures
to make them more palatable to the run-time interpreter.
The action of BAIL at compile time is governed by the value of the /B switch passed to
the compiler. If the value of this switch is zero (the default if no value is specified) then
BAIL is completely inactive. Otherwise, the low-order bits determine the actions which
BAIL performs. [The value of the /B switch is interpreted as octal.]
bit
action
1
lf this bit is on, then the .SMl file will contain the program counter to source/listing
text directory.
2
lf this bit is on, then the .SMl file will contain symbol information for ail SAIL
symbols encountered in the source. If this bit is off, then information is kept only
for procedures, parameters, blocks, and internals; i.e., non- internal local variables
are not recorded.
4
If this bit is on, then SIMPLE procedures will get procedure descriptors, and one
additional instruction (a JFCL 0, which is the fastest machine no-op instruction) is
inserted at the beginning of SIMPLE procedures. Except for these two changes, all
properties of SIMPLE procedures remain the same as before. The procedure
descriptor is necessary if the procedure, is to be called interpretively or if the
procedure is to be TRACEd.
‘10
If this bit -is on, then BAIL will not-be automatically loaded and initialized, although
all other actions requested are performed. This is primarily intended to make it
easier to debug new versions of BAIL without interfering with SYS:BAIL.REL. By
using this switch the decision to load BAIL is delayed until load time.
‘20
If this bit is on, then a request to load SYS:BAIPDn.REL is generated. This file
contains procedure descriptors for most of the SAIL predeclared runtime routines,
making it possible to call them from BAIL. The procedure descriptors and their
symbols occupy about 6K.
The 8 switch must occur on the binary term, not the listing or source term. Thus:
or
l OM PROG( 27B,)
.R SAIL
*PROG/27B+PROG
.
-
13
BAIL -- A debugger for SAIL
COMPILE-TIME ACTION
The progrm counter to source/listing index is kept in terms of coordinates. The
coordinate counter is zeroed at the beginning of the compilation and is incremented by
one for each BEGIN, ELSE, and semicolon seen by the parser, provided at least one word
of code has been compiled since the previous coordinate was defined. Note that
COMMENTS are seen only by the scanner, not the parser, and that DEFINE S and many
declarations merely define symbols and do not cause instructions to be generated. For
each coordinate the directory contains the coordinate number, the value of the program
counter, and a file pointer to the appropriate place. The appropriate place is the source
file unless a listing file is being produced and the CREF switch is off, in which case it is
the listing file. ’ [The listing file produced for CREF is nearly unreadable.], On a non-CREF
listing, the program counter is replaced by the coordinate number if bit 1 . of the /B
switch is on.
The symbol table informat ion consists of the block structure and the name, access
information; and type for each symbol.
lf a BEGIN-END pair has declarations (i.e., is a true block and not just a compound
statement) but does not have a name, then BAIL will invent one. The name is of the
form Bnnnn where nnnn is the decimal value of the current coordinate.
14
RUN-TIME ACTION
BAIL ,- A debugger for SAIL
SECTION 4
RUN-TIME ACTION
The BAIL run-time interpreter is itself a SAIL program which resides on the system disk
area, This program is usually loaded automatically, and does some initialization when
entered for the first time. The initialization generates a .BAI file of information collected
f r o m t h e .SMl files produced by separate compilations (if any). The .SM 1 files
correspond to .REL files, and the .BAl file corresponds to the .DMP or .SAV file, Like
RPG or CCL, BAIL will, try to bypass much of the initialization and use an existing l Al file
if appropriate. During initialization BAIL displays the names of the .SMl files it is
processing. For each .SMl file which contains program counter/text index information,
BAIL displays the names of the text files and determines whether the text files are
accessible.
The interpreter is activated by explicit call, previously inserted breakpoints, or the SAIL
error handler. For an explicit call, say EXTERNAL PROCEDURE BAIL; . . . BAIL;. From the
error handler, respond B. Breakpoints will be described later in this section.
I-
4.1
- Debugging Requests
When entered, BAIL prints the debugging recursion level followed by a colon, and awaits
a debugging request. BAIL accepts ALGOL and LEAP expressions of the SAIL language.
A complete description is given in [4] and in the addenda describing the syntax of
records and record-pointers. The following exceptions should be noted. Expressions
involving control structure are not allowed, hence BAIL will not recognize AND, CR, IFTHEN-ELSE, or CASE. Bracketed triple items are not allowed. The TO and FOR
substring and sublist operators have been extended to operate as array subscript
ranges, FOR PRINT-OUT ONLY. If FOO is an array, then FOO[3 TO 71; will act like FCC[3],
FCO[4], FOO[5], FOO[S], FOO[7]; but is easier to type. This extension is for print-out
only; no general APL syntax or semantics are provided.
BAIL evaluates symbolic names according to the scope rules of ALGOL, extended to
always recognize names which are globally unique and have a fixed memory location
(everything except parameters and recursive locals). For any activation of BAIL, the
initial scope is the ALGOL scope of the statement from which BAIL was activated. The
procedure SETLEX (see below) may be used to change the scope to that of any one of
the links in the dynamic activation chain.
.
-
Several procedures are predeclared in the outermost block to handle breakpoints and
display information. These are described individually below.
1 5
BAIL -- A debugger for SAIL
4.16 -
RUN-TIME ACTION
ARGS
STRING PROCEDURE ARGS;
The arguments to the procedure which was most recently called,
4.3
- BREAK
PROCEDURE BREAK( “locat ion”,“condit ion”{ NULL),“act ion”{ NULL),count (0));
BREAK inserts a breakpoint. The syntax for the first argument is
<Iocat ion> :;=<label>l<procedure>~~block name>l#<nnnn>
I<block name><delim><location~
any
character not legal in an identifier>
<deli m>::=<
<nnnn>..--<decimal coordinate number>
If the location is specified by the <block name><delim><location> construct then the
blocks of the core image are searched in ascending order of address of BEGINS until the
first <block name> is matched. The search continues until the second <block name> is
matched, etc. The breakpoint is inserted at the label, procedure, or coordinate declared
within the scope of the last <block name? This detailed specification is not usually
necessary, as shown in the examples. The last three parameters are default able and
need not be specified, again as in the examples. The action taken at a breakpoint is
IF LENGTH{ condi t ion) AND EVAL( condi t ion) AND (count +count - 1)x0 AND
LENGTH( action) THEN EVAL( act i on);
EVAL( TTY); .
Here EVAL is a procedure which evaluates its string argument and returns the value of
the last expression evaluated (similar to PROGN in LISP).
4.4
- DDT
PROCEDURE DDT; .
This procedure transfers control to an assembly language debugging program (if one was
loaded).
,
16
.
RUN-TIME ACTION
BAIL -- A debugger for SAIL
4.5
- HELP
PROCEDURE HELP;
A list of options, including short descriptions of the procedures described in this section,
is printed. A question mark followed by a carriage return is interpreted as a call to
HELP.
4.6
- SETLEX
PROCEDURE SETLEX(level);
Evaluating SETLEX(n) changes the static (lexical) scope to the scope of the n-th entry in
the dynamic scope list. SETLEX(0) is the scope of the breakpoint; SETLEX( 1) is the
scope of the most recent procedure call in the dynamic scope, etc.
4.7
- SHOW
STRING PROCEDURE SHOW( first, last(Q);
The text of the program from the source or listing file. If last is less than first then set
last to last+first, Return coordinates first through last. SHOW( 5,3) gives coordinates 5,
6, 7, and 8; SHOW( 5,7) gives coordinates 5, 6, and 7; SHOW{ 5) gives coordinate 5 only.
A plus sign (“+“) following the coordinate number indicates that the values of some
variables have been carried over in accumulators from the previous coordinate,
Changing the value of variables might not be successful in such a case, because BAIL will
not change any accumulator - value directly. The MEMORY construct can be used to
modify any location in a core image, including the accumulators.
4.8
- TEXT
STRING PROCEDURE TEXT;
The current static and dynamic scopes, with text from the source or listing file.
17
-
RUN-TIME ACTION
BAIL -- A debugger for SAIL
4.9 - TRACE
PROCEDURE TRACE( “procedure”);
Special breakpoints are inserted at the beginning and end of the procedure named. On
entry, the procedure name and arguments are typed. On exit, the name and value
returned (if any) are typed.
- TRAPS
4.10
STRING PROCEDURE TRAPS;
A list of the current breakpoints and. traces. ,
4.11
- UNBREAK
PROCEDURE UNBREAK( “locat ion”);
’
The breakpoint at the location specified is removed.
4.12
- UNTRACE
PROCEDURE UNTRACE(“procedure7;
The breakpoints inserted by TRACE are removed.
.
4.13 -
GO
pseudoPROCEDURE !!GO;
An immediate exit from the current instantiation of BAIL is taken and execution of the
program is resumed. !!GO is a reserved word (the only one) in BAIL.
18
?
RUN-TIME ACTION
BAIL -- A debugger for SAIL
4.14
- GSTEP
pseudoPROCEDURE !!GSTEP;
Temporary breakpoints are inserted at all of the logical exits of the current statement,
and execution of the program is resumed. Logical exits are the next statement and
locations to which the current statement can jump, excluding any procedure calls. All of
the breakpoints which are inserted will be removed as soon as one of them is
encountered.
4.15
- STEP
pseudoPROCEDURE !!STEP;
Temporary breakpoints are inserted at all locations. to which the current statement can
jump, including procedure calls, and execution of the program is resumed.
4.16
- STRING TYPEOUT
Strings are usually typed so that the output looks the same as the input, i.e., a string is
typed with surrounding quotation marks and doubled internal quotation marks. For
SHOW, ARGS, and TEXT this would ordinarily create confusion, so they are handled
specially. When these procedures are evaluated they set a flag which inhibits quotation
mark fiddling, provided that no further evaluation takes place before the next typeout.
Thus SHOW( 5,3); will be typed plain, but STR+SHOW(5,3); will have quotation marks
massaged.
4.17
- BAIL and DDT
If BAIL is initialized in a core image which does not have DDT or RAID, then things will be
set up so that the monitor command DDT gets you into BAIL in the right way. That is,
BAIL will be your DDT. To enter BAIL from DDT (provided that the SAIL initialization
sequence has already been performed), use
,
pushi P,<program counter>SX
JRST BAILBX
For example, if .JBOPC contains the program counter,
PUSH P,.JBOPCSX
19
BAIL --- A debugger for SAIL
JRST
BAILSX
RUN-TIME ACTION
,
’
The entry B. provides a path from DDT to BAIL which works whether or not the core
image has been initialized. One use of this feature is to BREAK a procedure in an
existing product ion program without recompiling. For example,
a; PROG originally compiled, loaded with BAIL and DDT, and’ SAVEd
@GET PROG
@DD
B.SG
BAIL initialization
:
1 :BREAK( “procedure”);
1 :!!GO;
SG
.
To enter DDT from BAIL, simply say DDT;. For operation under TENEX, control-B is a
pseudo-interrupt character which gets you into BAIL.
4!18 -
WARNINGS
Since BAIL is itself a SAIL procedure, entering BAIL from the error handier or DDT after
a push-down overflow or a string garbage collection error will get you into trouble.
SIMPLE procedures cause headaches for BAIL because they do not keep a display
pointer. [Indeed, the compiler gets lost in the following example, and does not complain:
BEGIN “LOST”
PROCEDURE A(INTEGER I); BEGIN “A”
SIMPLE PROCEDURE B; OUTSTR(“THE VALUE OF I IS ” & CVS( I));
PROCEDURE C(INTEGER J); B;
a 2);
END “A”;
AM;
END “LOST”;
1
BAIL tries valiantly to do the right thing, but occasionally it also gets lost. BAIL will try
to warn you if it can. In general, looking at value string parameters of SIMPLE
procedures does not work.
20
RESOURCES USED
BAIL -- A debugger for SAIL
SECTION 5
RESOURCES USED
I. Compile-time
A. One channel. This means that REQUlREd source files may only be nested to a
depth of about 9.
1
B. Memory. Up to 1 l*(maximum lexical nesting ‘depth) more words of memory may
be required compared with previous- compilations.
C, CPU time. Approximately 0.3 seconds per. page of dense text.
II. Run-t ime
A. Channels. Three during, initialization, two thereafter. Channels are obtained via
GETCHAN.
B. BAIL uses 7 of the privileged’ breaktables, obtaining them via GETBREAK.
C. REQUIRE 64 STRING!PDL. Necessary if the debugging recursion level will exceed
3 or 4.
D . M e m o r y . (9.5K +((# of coordinates+l27) DIV 128) + (2* # of blocks) + (58 # of
symbols)) words.
E. CPU time.
1, Initialization. Typically 4 seconds for a 30 page program.
2. Debugging requests. 0.07 seconds per simple request. DDT response time.
Ill. Disk space
A. The .SMl file for a /7B compilation is typically one-fourth the size of the
corresponding .REL file.
- B. The .BAl file for a group of /7B compilations is typically one-third the total size
of the corresponding .REL files.
21
.
BAIL -- A debugger for SAIL
,
CURRENT STATUS
SECTION 6
CURRENT STATUS
The state of the world is determined by the values of the accumulators and the value of
the SAIL variable !SKIP!.
The run-time interpreter recognizes only the first 15 characters of identifier names; the
rest are discarded without comment. The characters which are legal in identifiers are
ABCDEFGHIJKLMNOPQRSTU~WXYZ _
abcdefghijklmnopqrstuvwxyz
0l23456789!~a&rXc~V3+d!lI\~
Notable for its absence: period.
LOCATION of a procedure does not work.
PROPS is read-only.
Bracketed triple items are not allowed.
.
A procedure call containing the name of a parametric procedure (functional argument} is
not handled properly.
4
Contexts are not recognized.
The run-time interpreter will not recognize macros.
External linkage: If an identifier is never referenced by code (i.e., has an empty fixup
chain at the time fixups are put out to the loader) then that identifier is not defined by
SAIL. Thus variables which are never used do not take up space, and a request to the
loader is not -made for EXTERNALS which are not referenced. This feature of SAIL is
cast in concrete and will not be changed. As a result, the following DOES NOT WORK
unless special precautions are taken:.
BEGIN
EXTERNAL PROCEDURE BAIL;
EXTERNAL PROCEDURE PLOT(REAL XO,YO,Xl,Y 1);
,REQUIRE “CALCOM” LIBRARY;
BAIL END
PLOT will not be defined by SAIL, hence BAIL will not know about it. However if there
-
22
BAIL -- A debugger for SAIL
CURRENT STATUS
are any references to PLOT (real or “dummy” calls) then BAIL will know. The following
trick can also be used, assuming that CALCOM is a SAIL-compiled procedure: Compile
CALCOM with / 108, which says “make the SM 1 file but don’t automatically load
SY S:BAIL.REL”. Then the above will win (due to BAIL recognizing things which are
globally unique) and programs which do not use BAIL will not have it loaded just beacuse
the library was used. This same problem occurs with EXTERNAL RECORD!CLASS
declarations, Use of the subfield index information does not cause a reference to the
class name but NEW!RECORD does. Thus the same /lOB trick must be used if there are
no NEW!RECORD calls.
23
c
CURRENT STATUS
BAIL -- A debugger for SAIL
a
REFERENCES
tL
111
DECsystemlO Assembly Language Handbook DEC-100NRZC-D, Digital
‘Equipment Corporation, Maynard, Massachusetts, 1973.
PI
E d w i n t-l. Wterthwaite Jr., “Source Language Debugging Tools” (Ph.D. thesis),
Computer Science Department, St anford University, May .1975.
PI
Daniel C. Swinehart, “COPILOT: A Multiple Process Approach to Interactive
Programming Systems” (Ph.D. thesis), Computer Science Department, Stanford
3
University, August 1974.
141
Kurt VanLehn (ed.), SAIL USER MANUAL, Stanford Artificial Intelligence Labor& ory
memo AIM-204 (Computer Science Department report STAN-G-73-373), July
1973.
24