APPENDIX C: SYMBOLIC DEBUGGER ASSESSOR README FILE

INTRODUCTION:

The ACES Debugger Assessor is designed to test the functional capabilities of a symbolic debugger associated with an Ada compilation system. The Debugger Assessor consists of a set of programs to be invoked under the debugger, and a debugging "scenario" (set of operations to be performed while in the debugger) for each program. This "readme" file ("yb_readm.txt") provides instructions on operations to perform and information to collect for each program. Sample debugger command files showing the debugger commands used on a VMS system are also provided. A report form ("yb_tmplt.txt") for recording of test results and comments is provided.

Before running the Debugger Assessor tests, the user must have compiled packages zg_glob1, zg_glob2, zg_glob3, zg_glob4, zg_glob5, and zm_math. Also, an executable must have been created for zg_incld. See Pretest Steps 1 and 5.

Additionally, the user needs to compile, link, and execute the "zg_init" module. The "zc_adadb" command script should be used to compile the module, and the "zc_linkd" command script should be used to link the module. In order to execute the module, the user needs to decide how to invoke the "zg_init" module in debug mode. The user needs to recognize that the results need to be logged if assessing a cross-compiler (this would have been declared during Setup.) The user must do whatever initialization steps are necessary to execute the module and capture results (if appropriate). The end goal of running "zg_init" in debug mode is to generate the file "zg_cpy.db". If assessing a self-hosted compiler, simply copy or rename the file "zg_cpy.txt" to "zg_cpy.db" ("zg_cpy.txt" should have been generated by "zg_init" if assessing a self-hosted compiler). If assessing a cross-compiler, simply copy the log file to the file "zg_cpy.db" and edit the file. There are instructions within the file identifying which lines are to be deleted and which ones are to be saved.

The ACES Debugger Assessor contains 29 scenarios. Each scenario is independent and the scenarios can be run (or rerun) in any order. The user will adapt the debugger commands used in each scenario to the debugger being evaluated. Three programs may require adaptation: yb_12_a (interface to an assembly language subprogram), yb_12_b (test of inline machine code), and yb_14ta (tying tasks to interrupts).

PREPARING TO TEST:

1. Have these groups of files available:

a. Global files (those with the prefix of zg_*). These files are needed only if Pretest Step 5 has not been completed.

b. Math files (those with the prefix of zm_*). These files are needed only for yb_25_a, and are necessary only if Pretest Step 5 has not been completed.

c. Command files to compile/link with debug option.

These command files should have been adapted during Pretest:

(1) "zc_adadb.com"

(2) "zc_cpydb.com"

(3) "zc_linkd.com"

(4) "zc_setli.com"

d. Debugger Assessor files (those with the prefix of yb_*):

(1) Command files - Adapt these command files to the system under test. Both VAX VMS and UNIX versions of these files are provided. The VMS files have the suffix ".com" and the UNIX files have the suffix ".unx".

+ "yb_cmp1.com" - Compile 1 program under the debugger.

(2) Source files:

+ "yb_*.ada"

+ "yb_25_a.inc" (must have the timing loop code included)

The Ada files associated with Debugger Assessor scenario NN are named "yb_NN_*.ada" for programs with no tasking, and "yb_NNt*.ada" for programs with tasking. For example, there are two Ada files associated with Scenario 1, System State Information: "yb_01_a.ada" and "yb_01ta.ada".

(3) Sample assembly language file - This is a sample subprogram for VAX, and must be adapted to the system under test. Used in yb_12_a.

+ "ms_ilnul.mar"

(4) Sample Debugger Command files - "yb_*.com"

The sample VMS debugger command file associated with each test program has the same file prefix as the source file, and the suffix ".com". For example, there are two sample VMS command files for scenario 1: "yb_01_a.com" and "yb_01ta.com".

2. Execute zg_basln in Pretest Step 5, if it has not already been executed. This will compile the global files needed for the Debugger Assessor. Some systems may require that all units be compiled with a debug option. If this is the case, the global and math files must be recompiled with the appropriate option. Adapt a copy of the Pretest command scripts (zg_bas*) to compile the global and math files by calling "zc_adadb.com".

3. Fill out the descriptive information on the report form ("yb_tmplt.txt"). This calls for information on the identity of the system being tested, the hardware and software configuration used, the name of the tester, the date, and any other information a user may wish to note.

4. Adapt the debugger commands for each scenario.

Sample Debugger Assessor command language files ("yb_NN*.com") are distributed for a debugger running under the VMS compilation system. For most scenarios, the sample command files are intended as an example of the debugger commands to be entered interactively. Only Scenario 29 calls for executing a debugger command file. The user is encouraged to perform the scenarios interactively so that the quality and usability of the debugger can be better evaluated. Keeping command files of debugger commands will preserve a record of the operations performed and make it easier to duplicate the testing at a later date.

In many of the debugger scenarios, the instructions provide line numbers at which to set breakpoints. These line numbers are relative to the beginning of the source file. Several debuggers use different schemes for numbering lines; for example, a system might use numbers relative to the start of each compilation unit, or it might use Ada statement numbers. To simplify adapting to systems using other numbering techniques, all the ACES debugger source programs where line number breakpoints are set include comments on the right margin of each source line containing the file relative line number. (In addition, many breakpoints are given both by line number and by Ada label.) This will make it straightforward for a user to determine what number to use by searching the compilation listing file for the line number comment and observing how the system identifies the line.

EXECUTING THE TESTS:

The general steps for executing each debugger scenario are the same.

1. Compile and link the test with "yb_cmp1.com". "yb_cmp1.com" accepts one parameter, the test program file name (without a file extension). When reading the instructions for each scenario on preparing to test, remember that the "zg_basln" command file will have compiled the zg_glob* units and zm* units into the program library. If that step has been completed, there is no need to recompile these units for each scenario.

2. Adapt the debugger commands in "yb_NN*.com" debugger command file.

3. Invoke the test program under the debugger.

4. Perform debugging operations as instructed in this file.

ANALYZE/RECORD TEST RESULTS:

Answer questions on the Debugger Assessor report form ("yb_tmplt.txt") recording the debugger commands used at each step. Comments about usability should also be recorded.

=============================================================

DEBUGGER ASSESSOR TEST yb_01_a: System State Information

INTRODUCTION: Symbolic Debugger Assessor test yb_01_a tests the debugger capability to provide system state information. The system state information capability for a tasking program is tested in yb_01ta.

OVERVIEW OF TEST STEPS (yb_01_a):

Compile and execute test yb_01_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_01_a: System State Information

1. Does the debugger provide a command to identify the next statement to execute, including compilation unit and line number?

2. Does the debugger provide a command to display main program task time as CPU time, or number of machine instructions executed?

3. Does the debugger provide a command to display the program stack, including active subprograms, names and values of parameters and local variables?

4. Does the debugger provide a command to display program stack, including active subprograms, names and values of scalar parameters and local variables?

PREPARING TO TEST (yb_01_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_01_a.ada"

* "yb_01_a.com"

The program yb_01_a consists of three units. The first is the main procedure yb_01_a, which contains four subprograms, A, B, C, and D. Procedure yb_01_a calls A, A calls B, B calls C, and C calls D. The stack will be displayed in function D. The library package specification and body for package DESCR are also included. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which provides comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_01_a.ada"

Adapt this file to the host operating system:

* "yb_01_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_01_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_01_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_01_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in procedure B, line 162 << BREAKPOINT_1 >>

+ Set BREAKPOINT 2 in function D, line 97 << BREAKPOINT_2 >>

+ Set BREAKPOINT 3 in the main procedure yb_01_a, line 188

<< BREAKPOINT_3 >>

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide a command to identify the next statement to execute, including compilation unit and line number?

The debugger should display the compilation unit and the next statement to execute.

Compilation unit: yb_01_a.

Statement number: The numbering scheme may vary. Verify that line 162 "C(BLOCAL_1)"; is indicated as the next statement to execute.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 3: Does the debugger provide a command to display the program stack, including active subprograms, names and values of parameters, and local variables?

The debugger should display the stack, including active subprograms, names and values of parameters, and local variables. It is acceptable to use a few commands to get all the information, but it is not acceptable to have to issue a command to display each parameter and variable separately.



yb_01_a, A, B, C, D are on the stack.


Function D parameter list:

D_1: (1..10 => (STR => "**********",

B => FALSE,

X => 2.0,

I => 0,

J => 0,

c => BLUE))

Procedure C parameter list: C_1: 2.0

local variables: CLOCAL_1: (value same as D_1 above)


Procedure B parameter list: B_1: 2



B_2: (OUT parameter, value currently undefined)


local variables: BLOCAL_1: 2.0

Procedure A parameter list: A_1: YELLOW

A_2: (OUT parameter, value currently undefined)

local variables: ALOCAL_1: 2

ALOCAL_2: 0

Main Procedure yb_01_a

local variables: M_1: 0


COLOR_1: YELLOW


COLOR_2: WHITE

+ Answer NUMBER 4: Does the debugger provide a command to display program stack, including active subprograms, names and values of scalar parameters, and local variables?

This command should display the stack as above, but without displaying the values of composite types, arrays D_1 and CLOCAL_1. It is acceptable to use a few commands to get all the information, but it is not acceptable to have to issue a command to display each parameter and variable separately.

+ Continue execution.

* At BREAKPOINT 3:

+ Answer NUMBER 2: Does the debugger provide a command to display main program task time?

Display main program task time as CPU time or number of machine instructions executed.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_01ta: System State Information (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_01ta tests the debugger capability to provide system state information for a tasking program. Adapted from performance test tk_lf_task_52.

Program yb_01_a is used to test the debugger capability to provide system state information for a non-tasking program.

OVERVIEW OF TEST STEPS (yb_01ta):

Compile and execute test yb_01ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_01ta: System State Information (Tasking)

1. Does the debugger provide a command to display the identification of each task?

2. Does the debugger provide a command to display the type of each task?

3. Does the debugger provide a command to display the scope or owner of each task?

4. Does the debugger provide a command to identify the current statement of each task?

5. Does the debugger provide a command to display the status of each task?

PREPARING TO TEST (yb_01ta):

Have these files available:

* "zg_glob1.ada"

* "yb_01ta.ada"

* "yb_01ta.com"

The program yb_01ta consists of three units, the main procedure yb_01ta, and the library package specification and body of package DESCR. Procedure yb_01ta contains a task M_TASK, which allocates a record with a task type component. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "yb_01ta.ada"

Adapt this file to the host operating system:

* "yb_01ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_01ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_01ta):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where nn is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_01ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in Task M_TASK, line 137 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in DYNAMIC_RECORD.TASK_COMPONENT, line 93

<< BREAKPOINT_2 >>.

+ Follow the instructions at each breakpoint.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 5: Does the debugger provide a command to display the task status?

Display the status of each task. The status of M_TASK = RUNNING; the status of DYNAMIC_RECORD.TASK_COMPONENT = READY; yb_01ta is suspended waiting for dependents.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 1: Does the debugger provide a command to display task identification?

Verify that the identifications of DYNAMIC_RECORD.TASK_COMPONENT, M_TASK, and the main procedure task are correctly displayed.

+ Answer NUMBER 2: Does the debugger provide a command to display the task type?

Display the type of each task. The type of DYNAMIC_RECORD.TASK_COMPONENT = MINIMAL_TASK; the type of M_TASK = ANONYMOUS; the type of the main procedure task = ANONYMOUS.

+ Answer NUMBER 3: Does the debugger provide a command to display the scope or owner of the task?

Display the scope or owner of each task. The owner of DYNAMIC_REC is task M_TASK; the owner of M_TASK is procedure yb_01ta.

+ Answer NUMBER 4: Does the debugger provide a command to display the current statement?

Verify that the current statements of task M_TASK (line 137) and DYNAMIC_RECORD.TASK_COMPONENT (line 97) are correctly displayed.

+ Answer NUMBER 5: Does the debugger provide a command to display the task status?

Display the status of each task. The status of DYNAMIC_RECORD.TASK_COMPONENT = RUNNING. M_TASK is suspended on an call to entry REQUEST. Procedure yb_01ta is suspended waiting for dependents.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_02_a: Breakpoints

INTRODUCTION: Symbolic Debugger Assessor test yb_02_a tests the limitations on the breakpoint capability. The breakpoint capability for a tasking program is tested in yb_02ta.

OVERVIEW OF TEST STEPS (yb_02_a):

Compile and execute test yb_02_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_02_a : Breakpoints

1. Does the debugger support setting a breakpoint on a subprogram which is visible from the current location?

2. Does the debugger support setting a breakpoint on a subprogram which is not visible from the current location?

3. Does the debugger support setting a breakpoint on a subprogram with an ambiguous simple name?

4. Does the debugger support setting a breakpoint on an executable statement in the current procedure?

5. Does the debugger support setting a breakpoint on an executable statement in a procedure not yet entered?

6. Does the debugger support setting a breakpoint in a declarative region?

7. Does the debugger support setting a breakpoint in an exception handler?

8. Does the debugger support setting a breakpoint on a package body statement?

9. Does the debugger support setting a breakpoint to halt execution when any exception is raised? The breaks should occur on the statements raising exceptions.

10. Does the debugger support setting a breakpoint to halt execution when any subprogram is entered?

11. Does the debugger support a command to remove a breakpoint?

12. Does the debugger support a command to show all breakpoints?

NOTE: It is assumed that all breakpoints occur at the beginning of the line on which they are set.

PREPARING TO TEST (yb_02_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_02_a.ada"

* "yb_02_a.com"

The program yb_02_a consists of five units, including the main procedure yb_02_a, and the library package specification and body for package PACK_02. The library package specification and body for package DESCR are also included. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_02_a.ada"

Adapt this file to the host operating system:

* "yb_02_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_02_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_02_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_02_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in package body PACK_02, line 164 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in procedure yb_02_a, line 178.

+ Set BREAKPOINT 3 in procedure yb_02_a, line 247 << BREAKPOINT_3 >>.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 8: Does the debugger support setting a breakpoint on a package body statement?

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 6: Does the debugger support setting a breakpoint in a declarative region?

+ Continue execution.

* At BREAKPOINT 3:

+ Set BREAKPOINT 4 on procedure B.

+ Set BREAKPOINT 5 on line 237 in procedure B << BREAKPOINT_5 >>.

+ Set BREAKPOINT 8 on line 253 << BREAKPOINT_8 >>.

+ Continue execution.

* At BREAKPOINT 4:

+ Answer NUMBER 1: Does the debugger support setting a breakpoint on a subprogram which is visible from the current location? Procedure B was visible from procedure yb_02_a, where the breakpoint was set.

+ Set BREAKPOINT 6 on procedure yb_02_a.A.

+ Set BREAKPOINT 7 on function C.

+ Continue execution.

* At BREAKPOINT 5:

+ Answer NUMBER 5: Does the debugger support setting a breakpoint on an executable statement in a procedure not yet entered? The breakpoint was set from procedure yb_02_a.

+ Continue execution.

* At BREAKPOINT 6:

+ Answer NUMBER 3: Does the debugger support setting a breakpoint on a subprogram with an ambiguous simple name?

+ Continue execution.

* At BREAKPOINT 7:

+ Answer NUMBER 2: Does the debugger support setting a breakpoint on a subprogram which is not visible from the current location? The breakpoint was set in procedure B, from which C is not visible.

+ Continue execution.

* At BREAKPOINT 8:

+ Answer NUMBER 4: Does the debugger support setting a breakpoint on an executable statement in the current procedure? The breakpoint was set in procedure yb_02_a above.

+ Answer NUMBER 11: Does the debugger support a command to remove a breakpoint?

Remove BREAKPOINT 6 on Procedure A, and BREAKPOINT 7 on function C. Verify that BREAKPOINTS 6 and 7 are not taken again.

+ Answer NUMBER 12: Does the debugger support a command to show all breakpoints?

Issue a command to show all breakpoints. The breakpoints currently set are: breakpoints on DESCRIBE, B, line 237 of B, lines 178, 247, and 253 in yb_02_a, and line 164 in PACK_02.

+ Set BREAKPOINT 9 on line 280 << BREAKPOINT_9 >>.

+ Continue execution.

* At BREAKPOINT 9:

+ Answer NUMBER 7: Does the debugger support setting a breakpoint in an exception handler?

+ Set one breakpoint to break each time any exception is raised.

+ Set one breakpoint to break each time any subprogram is entered.

+ Continue execution.

* At BREAKPOINT 10:

+ The first of three breakpoints that must be taken to pass NUMBER 10. See instructions at BREAKPOINT 13.

+ Continue execution.

* At BREAKPOINT 11:

+ The second of three breakpoints that must be taken to pass NUMBER 10. See instructions at BREAKPOINT 13.

+ Continue execution.

* At BREAKPOINT 12:

+ The first of two breakpoints that must be taken to pass NUMBER 9. See instructions at BREAKPOINT 14.

+ Continue execution.

* At BREAKPOINT 13:

+ Answer NUMBER 10: Does the debugger support a breakpoint to halt execution when any subprogram is entered? Breaks must occur here, and at BREAKPOINTS 10 and 11.

+ Continue execution.

* At BREAKPOINT 14:

+ Answer NUMBER 9: Does the debugger support a breakpoint to halt execution when any exception is raised? Breaks must occur here and at BREAKPOINT 12.

+ Continue to the end of the program.

=============================================================

DEBUGGER ASSESSOR TEST yb_02ta: Breakpoints (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_02ta tests the limitations on the breakpoint capability for a tasking program. Adapted from performance test tk_ls_task_60. Test yb_02_a is used to test the breakpoint capability in a non-tasking program.

OVERVIEW OF TEST STEPS (yb_02ta):

Compile and execute test yb_02ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_02ta : Breakpoints (Tasking)

1. Does the debugger support a breakpoint to halt execution when any rendezvous occurs?

2. Does the debugger support a breakpoint to halt execution when any task switch occurs?

3. Does the debugger support a breakpoint to halt execution when any task is aborted?

Breaks on task abort may occur on the abort statement or in the task body when the task is terminated. It is better to break in both places, so that the programmer knows where the abort is initiated, and when the task is terminated.

PREPARING TO TEST (yb_02ta):

Have these files available:

* "zg_glob1.ada"

* "yb_02ta.ada"

* "yb_02ta.com"

The program yb_02ta consists of three units, the main procedure yb_02ta, and the library package specification and body for package DESCR. Procedure yb_02ta contains a task MAIN and three tasks which call MAIN. MAIN accepts each request in lexical order and then aborts the calling tasks. MAIN will run before the requester tasks, and will block on an accept for REQUEST1. REQUESTER3, REQUESTER2, and REQUESTER1, will then run and block on entry calls. MAIN will then accept each entry call, and then abort the requester tasks. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "yb_02ta.ada"

Adapt this file to the host operating system:

* "yb_02ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_02ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_02ta):

* Invoke the debugger for yb_02ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set one breakpoint to break when any rendezvous occurs.

+ Set one breakpoint to break when any task switch occurs.

+ Set one breakpoint to break when any task is aborted.

Only these three breakpoints are to be set.

BREAKPOINTS 1 - 3 are breaks on task switches, BREAKPOINTS 4 - 6 are breaks on rendezvous, and BREAKPOINTS 7 - 9 are breaks on task aborts. The numbered breakpoints must occur in numerical order, but will be interspersed with other breaks on task switches, the number and location of which will vary depending on the system.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 3: Does the debugger support a breakpoint to halt execution when any task is aborted? The break on task abort may occur here and/or at BREAKPOINT 9, line 199.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 3: Does the debugger support a breakpoint to halt execution when any task is aborted? The break on task abort may occur here and/or at BREAKPOINT 8, line 198.

+ Continue execution.

* At BREAKPOINT 3:

+ Answer NUMBER 2: Does the debugger support a breakpoint to halt execution when any task switch occurs? Verify that breaks occur on BREAKPOINTS 1 - 3.

+ Answer NUMBER 3: Does the debugger support a breakpoint to halt execution when any task is aborted? The break on task abort may occur here and/or at BREAKPOINT 7, line 197.

+ Continue execution.

* BREAKPOINT 4: Break on rendezvous.

* BREAKPOINT 5: Break on rendezvous.

* At BREAKPOINT 6: Break on rendezvous.

+ Answer NUMBER 1: Does the debugger support a breakpoint to halt execution when any rendezvous occurs? BREAKPOINTS 4, 5, and 6 should have occurred on rendezvous.

+ Continue execution.

* BREAKPOINT 7: Break on task abort.

* BREAKPOINT 8: Break on task abort.

* At BREAKPOINT 9: Break on task abort.

+ Answer NUMBER 3: Does the debugger support a breakpoint to halt execution when any task is aborted? BREAKPOINTS 7, 8, and 9 may occur on the abort statements, or in the aborted tasks. It is better to break in both places. Note the location of the break.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_03_a: Single Stepping

INTRODUCTION: Symbolic Debugger Assessor test yb_03_a tests the single step capability. The single step capability for a tasking program is tested in yb_03ta.

OVERVIEW OF TEST STEPS (yb_03_a):

Compile and execute test yb_03_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_03_a: Single Stepping

1. Does the debugger provide the capability to step from one statement to the next?

2. Does the debugger provide the capability to step to an appropriate handler when a statement raises an exception?

3. Does the debugger provide an option to step through subprogram statements when the current line contains a subprogram call?

4. When stepping through subprogram statements, does stepping continue in an exception handler when an exception is raised?

5. Does the debugger provide an option to break on return from a subprogram when the current line contains a subprogram call?

6. When option to break on return is in effect, does stepping resume in an exception handler if subprogram raises exception?

7. Does the debugger provide an option to execute a specified number of statements?

PREPARING TO TEST (yb_03_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_03_a.ada"

* "yb_03_a.com"

The program yb_03_a consists of three units, including the main procedure yb_03_a, and the library package specification and body for package DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_03_a.ada"

Adapt this file to the host operating system:

* "yb_03_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_03_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_03_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_03_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE: Continue to the beginning of the main program, and then issue command(s) to single step through the code (execute one statement at a time, breaking after each statement). Follow the instructions in the program comments.

* At Line 121:

+ Answer NUMBER 1: Does the debugger provide the capability to step from one statement to the next? Issue a command to single step, and verify that a break occurs after each statement.

+ Continue stepping.

* At Line 129:

+ Answer NUMBER 3: Does the debugger provide an option to step through subprogram statements when the current line contains a subprogram call? Issue a command to step to the procedure, and step through the statements in the procedure. After the subprogram is complete, the debugger should step to the statement after the call.

+ Continue stepping.

* At procedure P01 (Line 88):

Step through subprogram statements. Stepping should continue in the main procedure on return from the subprogram. (NUMBER 3)

* At Line 139:

+ Answer NUMBER 2: Does the debugger provide the capability to step to the appropriate handler when a statement raises an exception? Verify that the stepping continues in the exception handler below.

+ Continue stepping.

* At Line 149: Stepping should continue in exception handler. (NUMBER 2)

* At Line 155:

+ Answer NUMBER 4: When stepping through subprogram statements, does stepping continue in an exception handler when an exception is raised? Issue a command to step through the statements in the procedure. Verify that stepping continues in the handler below, after the procedure raises an exception.

+ Continue stepping.

* At procedure P02 (Line 97): Step through subprogram statements. Stepping should continue in the exception handler in the main procedure. (NUMBER 4)

* At Line 164: Stepping should continue in exception handler. (NUMBER 4)

* At Line 170:

+ Answer NUMBER 5: Does the debugger provide an option to break on return from a subprogram when the current line contains a subprogram call? Issue a command to break on return from the subprogram. Verify that the subprogram is not stepped to, and that stepping continues on return from the subprogram.

+ Continue stepping.

* At Line 180:

+ Answer NUMBER 6: When the option to break on return is in effect, does stepping resume in an exception handler if the subprogram raises an exception? Issue a command to break on return from the subprogram. Verify that the subprogram is not stepped to, and that stepping continues in the exception handler below.

+ Continue stepping.

* At Line 189: Stepping should continue in exception handler. (NUMBER 6)

* At Line 194:

+ Answer NUMBER 7: Does the debugger provide an option to execute a specified number of statements?

+ Issue a command to step 3 statements.

* At Line 200:

+ Stepping should continue at this statement. (NUMBER 7)

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_03ta: Single Stepping (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_03ta tests the single step capability for a tasking program. Test yb_03_a is used to test the single step capability for a non-tasking program.

OVERVIEW OF TEST STEPS (yb_03ta):

Compile and execute test yb_03ta under the debugger. Answer the following question and record the results on the Symbolic Debugger Assessor Summary Report.

yb_03ta: Single Stepping (Tasking)

1. Does the debugger support stepping to next statement when next statement is in a different task?

PREPARING TO TEST (yb_03ta):

Have these files available:

* "zg_glob1.ada"

* "yb_03ta.ada"

* "yb_03ta.com"

The program yb_03ta consists of three units, the main procedure yb_03ta, and the library package specification and body for package DESCR. Procedure yb_03ta contains tasks MAKE and TAKE. TAKE calls MAKE.ENTRY1 three times, and then stops MAKE with a call to MAKE.STOP. MAKE will run first. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "yb_03ta.ada"

Adapt this file to the host operating system:

* "yb_03ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_03ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_03ta):

* Invoke the debugger for yb_03ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ This program contains two tasks, MAKE and TAKE. Issue command(s) to single step (execute one statement at a time, breaking after each statement) and verify that stepping continues from one statement to the next when task switches occur between statements. TAKE will call MAKE.ENTRY1 three times, receiving a character each time, and will then stop MAKE with a call to MAKE.STOP.

+ Continue stepping.

* Line 82: When a call to ENTRY1 is received, the accept statement will be executed, and then MAKE will be suspended while waiting for another call. A task switch will occur.

* Line 106:

+ Verify that stepping occurs between tasks. A task switch will occur after each entry call.

+ Answer NUMBER 1: Does the debugger support stepping to next statement when next statement is in a different task?

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_04_a: Examination of Variables

INTRODUCTION: Symbolic Debugger Assessor test yb_04_a tests the debugger capability to examine variables (non_tasking). Test yb_04ta is used to test examination of variables in a tasking program.

OVERVIEW OF TEST STEPS (yb_04_a):

Compile and execute test yb_04_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_04_a : Examination of Variables

1. Does the debugger support examination of a variable in a library package body which is directly visible at the current location (WITHed at current location)?

2. Does the debugger support examination of a variable in a library package which is not directly visible from the current location (elaborated but not WITHed at current location)?

3. Does the debugger support examination of a variable in a library package which is a generic instantiation?

4. Does the debugger support examination of a locally declared variable?

5. Does the debugger support examination of a variable with an ambiguous simple name? A qualified reference should be permitted.

6. Does the debugger support examination of a formal parameter?

7. Does the debugger support examination of a predefined integer type variable?

8. Does the debugger support examination of a predefined float type variable?

9. Does the debugger support examination of an enumeration type variable?

10. Does the debugger support examination of a fixed point type variable?

11. Does the debugger support examination of an array type variable?

12. Does the debugger support examination of a record type variable with discriminants? The discriminant and all fields should be displayed.

13. Does the debugger support examination of a record type variable with an unconstrained object? The constraint should be displayed.

14. Does the debugger support examination of an access type variable? It should be possible to display both the access value and the object to which it refers.

15. Does the debugger support examination of a named number?

16. Does the debugger support examination of the name of an exception being handled?

17. Does the debugger support examination of the attributes of a variable?

PREPARING TO TEST (yb_04_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_04_a.ada"

* "yb_04_a.com"

The program yb_04_a consists of seven units: the main procedure yb_04_a, the specification and body of package INVISIBLE, the specification and body of generic package PACK_EXCHANGE, and the specification and body of package DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_04_a.ada"

Adapt this file to the host operating system:

* "yb_04_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_04_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_04_a):

Breakpoints are given by line number and, where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_04_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in function RAISE_EXC, line 263 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in procedure COUNT_LETTERS, line 247 << BREAKPOINT_2 >>.

+ Set BREAKPOINT 3 in procedure EXCHANGE, line 158.

+ Set BREAKPOINT 4 in procedure yb_04_a, line 289 << BREAKPOINT_4 >>. At each breakpoint, examine the variables indicated.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 16: Examine the name of the exception being handled. The name should be "USER_EXCEPTION".

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 4: Examine a locally declared variable.

Examine INDEX = 9.

+ Answer NUMBER 5: Examine variable with ambiguous simple name.

Examine yb_04_a.INDEX = 20.

+ Answer NUMBER 6: Examine formal parameters.

Examine STR_IN = "******** ."

Examine COUNT = 8.

+ Continue execution.

* At BREAKPOINT 3:

+ Answer NUMBER 3: Examine variables in a generic instantiation.

Examine T = 0, U = 8, V = 0.

+ Continue execution.

* At BREAKPOINT 4:

+ Answer NUMBER 1: Examine a variable in a WITHed library package.

Examine DESCR.DESCR_X = 1.0.

+ Answer NUMBER 2: Examine a variable in a library package elaborated but not WITHed.

Examine INVISIBLE.A_REAL = 12.5.

+ Answer NUMBER 7: Examine a predefined integer type variable.

Examine M_0 = 8, M_1 = 0.

+ Answer NUMBER 8: Examine a predefined float type variable.

Examine M_2 = 1.0.

+ Answer NUMBER 9: Examine an enumeration type variable.

Examine PAINT = YELLOW.

+ Answer NUMBER 10: Examine a fixed point type variable.

Examine M_3 = 0.25.

+ Answer NUMBER 11: Examine an array type variable.

Examine ARRAY1 = (1..19 => 5.8, 20 => 0.25).

+ Answer NUMBER 12: Examine a record with discriminants.

Examine PERSON1 = ( MARITAL_STATUS => M,

GIVEN_NAME => SUSAN,

BIRTH_YEAR => 60,

SPOUSE => ARTHUR).

+ Answer NUMBER 13: Examine a record with an unconstrained object.

Examine VAR_STRING.ALL. VAR_STRING.LEN is the string

constraint.

VAR_STRING.STR = "********"

VAR_STRING.LEN = 12

+ Answer NUMBER 14: Examine an access type variable.

Examine BOOL_PTR, both the access value (pointer) and the object to

which it refers.

BOOL_PTR = (address)

BOOL_PTR.ALL = true

+ Answer NUMBER 15: Examine a named number.

Examine NAMED_NUM = 0.25.

+ Answer NUMBER 17: Examine the attributes of a variable.

Examine the attributes of PERSON1.GIVEN_NAME.

PERSON1.GIVEN_NAME'FIRST = 1

PERSON1.GIVEN_NAME'LAST = 10 PERSON1.GIVEN_NAME'RANGE = 1..10 PERSON1.GIVEN_NAME'LENGTH = 10

PERSON1.GIVEN_NAME'SIZE = (size)

PERSON1.GIVEN_NAME'ADDRESs = (address)

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_04ta: Examination of Variables (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_04ta tests the debugger capability to examine variables (tasking). Adapted from tk_lf_task_52. Test yb_04_a is used to test examination of variables in a non-tasking program.

OVERVIEW OF TEST STEPS (yb_04ta):

Compile and execute test yb_04ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_04ta: Examination of Variables (Tasking)

1. Does the debugger support examination of a record type with a task type component? The task identification should be displayed.

2. Does the debugger support examination of a task type variable? The task identification should be displayed.

3. Does the debugger support examination of the attributes of a task type variable?

PREPARING TO TEST (yb_04ta):

Have these files available:

* "zg_glob1.ada"

* "yb_04ta.ada"

* "yb_04ta.com"

The program yb_04ta consists of three units, the main procedure yb_04ta, and the library package specification and body for package DESCR. Procedure yb_04ta contains a task MAIN, which declares a task type variable TASK_VAR, and a record TASK_REC, which contains a task type component. Variables TASK_VAR and TASK_REC will be examined. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "yb_04ta.ada"

Adapt this file to the host operating system:

* "yb_04ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_04ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_04ta):

Breakpoints are given by line number and, where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_04ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in MAIN task body, line 125 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in MINIMAL_TASK_2 body, line 103 << BREAKPOINT_2 >>. At each breakpoint, examine the specified variables.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Examine a record with a task type component. Examine TASK_REC. The task identification should be displayed.

+ Answer NUMBER 2: Examine a task type variable. Examine TASK_VAR. The task identification should be displayed.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 3: Examine the attributes of a task type variable.

Examine the attributes of TASK_VAR using Ada notation:

TASK_VAR'ADDRESS = (address)

TASK_VAR'CALLABLE = TRUE

TASK_VAR.REQUEST_1'COUNT = 1

TASK_VAR'STORAGE_SIZE = (storage size)

TASK_VAR'TERMINATED = no

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_05_a: Interrupt Execution and Return Control to Debugger

INTRODUCTION: Symbolic Debugger Assessor test yb_05_a tests the debugger capability to interrupt program execution and return control to the debugger.

OVERVIEW OF TEST STEPS (yb_05_a):

Compile and execute test yb_05_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_05_a : Interrupt Execution and Return Control to Debugger

1. Does the debugger provide a command to interrupt program execution and return control to the debugger, so that debugger commands may be issued?

PREPARING TO TEST (yb_05_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_05_a.ada"

* "yb_05_a.com"

The program yb_05_a consists of three units: the main procedure yb_05_a, and the library package specification and body of the package DESCR. Procedure yb_05_a contains an infinite loop; the program will be interrupted and a variable X will be examined. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_05_a.ada"

Adapt this file to the host operating system:

* "yb_05_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_05_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_05_a):

* Invoke the debugger for yb_05_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE: This program will fall into an infinite loop. Continue execution, then issue a debugger command which allows program execution to be interrupted without ending the debugging session. After program execution is interrupted, it should be possible to issue debugger commands.

* After interrupting:

+ Answer NUMBER 1: Does the debugger provide a command to interrupt program execution and return control to the debugger?

+ Examine X. Verify that the command is accepted and the correct value is given.



--


WHILE X = 0 LOOP -- x = 0 -- 70

X := ZG_GLOB4.TEN; -- x = 10 after this statement -- 71

ZG_GLOB4.PROCI1 (X); -- x = 10 after this statement -- 72

X := X - 10; -- x = 0 after this statement -- 73

END LOOP;

--


* Exit the debugger; the program will not terminate.

=============================================================

DEBUGGER ASSESSOR TEST yb_06_a: Watchpoints

INTRODUCTION: Symbolic Debugger Assessor test yb_06_a tests the debugger capability to set a watchpoint on an object, breaking when the value changes or a specific value is reached.

OVERVIEW OF TEST STEPS (yb_06_a):

Compile and execute test yb_06_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_06_a: Watchpoints

1. Does the debugger support a watchpoint on a static object in a library package?

2. Does the debugger support a watchpoint on a locally declared variable in the main program?

3. Does the debugger support a conditional watchpoint on a (visible) variable local to a subprogram which is called many times before the variable reaches the target value?

4. Does the debugger support a watchpoint on a (not visible) variable local to a subprogram?

5. Does the debugger support a watchpoint on a variable declared within an allocated object?

6. Does the debugger support a watchpoint on a formal parameter?

7. Does the debugger support a watchpoint on a variable modified by direct assignment?

8. Does the debugger support a watchpoint on an actual parameter modified in a subprogram?

9. Does the debugger support a watchpoint on a component of a record, modified by assignment to the entire record?

10. Does the debugger support a watchpoint on a variable in an allocated object, modified by one of several access variables?

11. Does the debugger support a watchpoint on a formal parameter modified under an alias?

12. Does the debugger support a watchpoint on a deallocated object?

13. Does the debugger support a watchpoint on a named collection?

PREPARING TO TEST (yb_06_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_06_a.ada"

* "yb_06_a.com"

The program yb_06_a consists of five units: the main procedure yb_06_a, the library package specification and body of PACK_DBG06, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_06_a.ada"

Adapt this file to the host operating system:

* "yb_06_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_06_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_06_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

NOTE: Some systems will not detect a watchpoint until the statement containing it has completed. Some of the line numbers listed below may be off by one.

* Invoke the debugger for yb_06_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in procedure yb_06_a, line 254 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in procedure A, line 201 << BREAKPOINT_2 >>.

+ Set BREAKPOINT 3 in procedure B, line 177 << BREAKPOINT_3 >>.

At each breakpoint set the specified watchpoints. Execution should halt at the lines marked "<<< WATCHPOINT". There are 13 watchpoints.

+ Continue execution.

* At BREAKPOINT 1:

+ Set a watchpoint on PACK_DBG06.P06. (NUMBER 1)

+ Set a watchpoint on M_1. (NUMBER 2)

+ Set a watchpoint on ALOCAL_1. (NUMBER 4)

+ Set a watchpoint on ACCESS_1.ALL.BOOL. (NUMBERS 5, 10, and 12)

+ Set a watchpoint on M_2. (NUMBER 8)

+ Set a watchpoint on RECORD_1.STRNG. (NUMBER 9)

+ Set a watchpoint on collection for access type ARECORD_PTR. (NUMBER 13)

+ Continue execution.

* At BREAKPOINT 2:

+ Set a watchpoint on A_3. (NUMBER 6)

+ Set a watchpoint on A_1. (NUMBER 11)

+ Continue execution.

* At BREAKPOINT 3:

+ Set a watchpoint to break when BLOCAL_1 = 5 (NUMBER 3). It should not be necessary to reset the watchpoint each time the procedure is entered. If the watchpoint is not automatically reactivated, then it may be possible to use a macro or some other (1 time) command to reset the watchpoint each time the procedure is entered. Cancel this breakpoint on B.

+ Continue execution.

* At WATCHPOINT 1 (line 205):

+ Answer NUMBER 4: Does the debugger support a watchpoint on a (not visible) variable local to a subprogram? The watchpoint was set in yb_06_a at BREAKPOINT 1.

ALOCAL_1 = red

+ Continue execution.

* At WATCHPOINT 2 (line 187):

+ Answer NUMBER 3: Does the debugger support a watchpoint on a (visible) variable local to a subprogram which is called many times before the variable reaches the target value? Six calls will be made to the subprogram, but the watchpoint should be triggered only when BLOCAL_1 = 5.

+ Continue execution.

* At WATCHPOINT 3 (line 225):

+ Answer NUMBER 11: Does the debugger support a watchpoint on a formal parameter which is modified by assignment to its actual parameter? This assignment should trigger a watchpoint on A_1, which is the formal parameter corresponding to ARRAY_1.

ARRAY_1 = 10,2,3,4,5,6,7,8,9,10 = A_1

+ Continue execution.

* At WATCHPOINT 4 (line 236):

+ Answer NUMBER 6: Does the debugger support a watchpoint on a formal parameter? This assignment should trigger a watchpoint on A_3.

A_3 = 2

+ Continue execution.

* At WATCHPOINT 5 (line 267):

+ Answer NUMBER 8: Does the debugger support a watchpoint on an actual parameter modified in a subprogram? The formal parameter A_2, corresponding to actual parameter M_2, was modified in A at line 217. Scalar parameters are passed by copy, so the watchpoint should be triggered at copy-back on return from A.

M_2 = 0.49991

+ Continue execution.

* At WATCHPOINT 6 (line 279):

+ Answer NUMBER 1: Does the debugger support a watchpoint on a static object in a library package, which may be statically allocated?

P06 = 0.49991

+ Continue execution.

* At WATCHPOINT 7 (line 287):

+ Answer NUMBER 2: Does the debugger support a watchpoint on a variable locally declared in the main program?

M_1 = 10

+ Answer NUMBER 7: Does the debugger support a watchpoint on a variable modified by direct assignment? M_1 is modified by direct assignment.

+ Continue execution.

* At WATCHPOINT 8 (line 298):

+ Answer NUMBER 9: Does the debugger support a watchpoint on a component of a record which is modified by assignment to the entire record? This assignment should trigger a watchpoint on RECORD_1.STRNG.

RECORD_1.STRNG = "abcdefghij"

+ Continue execution.

* At WATCHPOINT 9 (line 308):

+ Answer NUMBER 5: Does the debugger support a watchpoint on a variable within an allocated object?

ACCESS_1.ALL.BOOL = true

+ Continue execution.

* At WATCHPOINT 10 (line 314):

+ Answer NUMBER 10: Does the debugger support a watchpoint on an allocated object modified by several access variables? This assignment should trigger a watchpoint on ACCESS_1.ALL.BOOL.

+ Continue execution.

+ A spurious breakpoint can occur at line number 322 due to the watch_point on ACCESS_1.ALL_BOOL if UNCHECKED_DEALLOCATION clears objects pointed to. If such a break occurs, ignore it and continue.

* At WATCHPOINT 11 (line 324):

+ Answer NUMBER 12: Does the debugger support a watchpoint on a deallocated object modified by another access variable? This assignment should trigger a watchpoint on ACCESS_1.ALL.BOOL.

+ Continue execution.

* At WATCHPOINT 12 (line 332):

+ Answer NUMBER 13: Does the debugger support a watchpoint on a named collection which is modified by allocating and deallocating space in it? This statement should trigger a watchpoint on the collection for access type ARECORD_PTR, because space is allocated. See WATCHPOINT 13.

+ Continue execution.

* At WATCHPOINT 13 (line 345):

+ Answer NUMBER 13: Does the debugger support a watchpoint on a named collection which is modified by allocating and deallocating space in it? This statement should trigger a watchpoint on the collection for access type ARECORD_PTR, because space is deallocated.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_07_a: Traceback of Subprogram History

INTRODUCTION: Symbolic Debugger Assessor test yb_07_a tests the debugger capability to display a traceback of subprogram history (the sequence of calls). The capability to display a traceback of calls for a tasking program is tested in yb_07ta.

OVERVIEW OF TEST STEPS (yb_07_a):

Compile and execute test yb_07_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_07_a: Traceback of Subprogram History

1. When the subprogram history is displayed, are names of subprograms correctly displayed?

2. When the subprogram history is displayed, are statement numbers of calls given?

PREPARING TO TEST (yb_07_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_07_a.ada"

* "yb_07_a.com"

The program yb_07_a consists of five units: the main procedure yb_07_a, the library package specification and body of PACK_DBG07, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_07_a.ada"

Adapt this file to the host operating system:

* "yb_07_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_07_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_07_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_07_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in procedure PACK_DBG07.DBG07_20, line 111

<< BREAKPOINT_1 >>.

+ Continue execution.

* At BREAKPOINT 1:

+ Issue a command to display the subprogram history (the chain of calls up to this point).

+ Answer NUMBER 1: Are the names of the subprograms correctly displayed?

Procedure yb_07_a calls DBG07_1

Subprogram DBG07_X calls DBG07_X+1 for X = 1..19

+ Answer NUMBER 2: Are the statement numbers of the calls given? Numbering schemes may vary. The second statement after the "BEGIN" of each subprogram is the call.

yb_07_a : line 259

DBG07_1 : line 243

DBG07_2 : line 237

DBG07_3 : line 231

DBG07_4 : line 225

DBG07_5 : line 219

DBG07_6 : line 212

DBG07_7 : line 204

DBG07_8 : line 197

DBG07_9 : line 189

DBG07_10 : line 183

DBG07_11 : line 177

DBG07_12 : line 171

DBG07_13 : line 165

DBG07_14 : line 159

DBG07_15 : line 153

DBG07_16 : line 147

DBG07_17 : line 141

DBG07_18 : line 135

DBG07_19 : line 129

DBG07_20 : line 111

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_07ta: Traceback of Subprogram History (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_07ta tests the debugger capability to display a traceback of subprogram calls in a tasking program. The capability to display a traceback of calls for a non-tasking program is tested in yb_07_a.

OVERVIEW OF TEST STEPS (yb_07ta):

Compile and execute test yb_07ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_07ta: Traceback of Subprogram History (Tasking)

1. When the subprogram history is displayed, are names of tasks and subprograms correctly displayed?

2. When the subprogram history is displayed, are statement numbers of calls given?

PREPARING TO TEST (yb_07ta):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_07ta.ada"

* "yb_07ta.com"

The program yb_07ta consists of five units: the main procedure yb_07ta, the library package specification and body of PACK_DBG07T, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_07ta.ada"

Adapt this file to the host operating system:

* "yb_07ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_07ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_07ta):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_07ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in procedure PROC_D, line 91 << BREAKPOINT_1 >>. At the breakpoint, issue a command to display a traceback of subprogram history (the chain of calls up to that point).

+ Continue execution.

* At BREAKPOINT 1:

+ Issue a command to display the subprogram history.

+ Answer NUMBER 1: Are the names of the subprograms and tasks correctly displayed?

Task TASK_B calls procedure PROC_C. Procedure PROC_C calls procedure PROC_D. In addition the debugger may mention that task TASK_A calls ENTRY1 of task TASK_B. This information is not required, however, since this is an entry call, and not a subprogram call.

+ Answer NUMBER 2: Are the statement numbers of the calls given? Numbering schemes may vary. The second statement after the "begin" of each subprogram or task is the call.

TASK_A : line 125

TASK_B : line 117

PROC_C : line 111

PROC_D : line 91

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_08_a: Program History

INTRODUCTION: Symbolic Debugger Assessor test yb_08_a tests the debugger capability to display the program history (the execution path of the program).

OVERVIEW OF TEST STEPS (yb_08_a):

Compile and execute test yb_08_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_08_a: Program History

1. Does the debugger provide the capability to display the program history?

The debugger may provide a cyclic buffer which records the execution path of the program, or it may be necessary to use a trace file to determine what path was taken.

PREPARING TO TEST (yb_08_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_08_a.ada"

* "yb_08_a.com"

The program yb_08_a consists of three units: the main procedure yb_08_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_08_a.ada"

Adapt this file to the host operating system:

* "yb_08_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_08_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_08_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_08_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 at line 74 << BREAKPOINT_1 >>. At the breakpoint, issue a command to display the program history (the statements executed up to that point).

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to display the program history (the statements executed)? Display the program history and verify that the statements executed are correctly displayed. The statements executed are shown below.



--


BEGIN -- 62

X := X + ZG_GLOB4.MM; -- x = 3 -- executed -- 63

Y := Y + ZG_GLOB4.II; -- y = 3 -- executed -- 64

IF X = Y THEN -- executed -- 65

X := X + ZG_GLOB4.TEN; -- executed -- 66

ELSIF X = ZG_GLOB4.LL THEN -- 67


X := X + ZG_GLOB4.EI; -- not executed -- 68


ELSE -- 69


X :=X + ZG_GLOB4.II; -- not executed -- 70


END IF; -- 71

--


- Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_09_a: Modification of Variables

INTRODUCTION: Symbolic Debugger Assessor test yb_09_a tests the debugger capability to modify variables.

OVERVIEW OF TEST STEPS (yb_09_a):

Compile and execute test yb_09_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_09_a: Modification of Variables

1. Does the debugger support modification of a variable referenced by an access type variable?

2. Does the debugger support modification of variable in a package?

3. Does the debugger support modification of a local variable?

4. Does the debugger support modification of a constant?

5. Does the debugger support modification of a named number?

6. Are Ada constraints enforced?

PREPARING TO TEST (yb_09_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_09_a.ada"

* "yb_09_a.com"

The program yb_09_a consists of five units: the main procedure yb_09_a, the library package specification and body of PACK_DBG09, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_09_a.ada"

Adapt this file to the host operating system:

* "yb_09_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_09_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_09_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_09_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in procedure yb_09_a, line 127 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in procedure A, line 118 << BREAKPOINT_2 >>. At each breakpoint, modify the specified variables, and verify that the value has been changed.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Modify a variable referenced by an access type. STRING_PTR1.ALL = "abcd". Set STRING_PTR1.ALL to "****", and examine it to verify the value.

+ Answer NUMBER 2: Modify a variable in a package. P09 = 1.0. Set P09 to 100.0 and examine it to verify the value.

+ Answer NUMBER 4: Modify a constant. CONST = GREEN. Set CONST to BLACK and examine it to verify the value.

+ Answer NUMBER 5: Modify a named number. NAMED_NUM = 0.98. Set NAMED_NUM to 0.001 and examine it to verify the value.

+ Answer NUMBER 6: Are Ada constraints enforced when variables are modified? In each of the following cases, a message should be issued that the assignment violates constraints. If an obvious type conversion is possible (integer to ZG_GLOB1.FLOAT6), the assignment may be performed.

The current value of RECORD1.ALL is (FIELD_1 => "xxx"

FIELD_2 => 0.0

FIELD_3 => RED

FIELD_4 => 1).

Set RECORD1.ALL.FIELD_1 to "1234". This is an index constraint violation. Set RECORD1.ALL.FIELD_2 to 4. This is a type violation, but conversion is possible. Set RECORD1.ALL.FIELD_3 to 14.8. This is a type violation. Set RECORD1.ALL.FIELD_4 to 11. This is a range constraint violation. Set STRING_PTR2 to RECORD1. This is an access type violation.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 3: Does the debugger support modification of a local variable? Modify a local variable. ALOCAL_1 = TRUE. Set ALOCAL_1 to FALSE. Examine ALOCAL_1 to verify the value.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_10_a: Control Flow Direction

INTRODUCTION: Symbolic Debugger Assessor test yb_10_a tests the debugger capability to modify control flow direction.

OVERVIEW OF TEST STEPS (yb_10_a):

Compile and execute test yb_10_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_10_a: Control Flow Direction

1. Does the debugger provide the capability to restart a program from the beginning?

2. Does the debugger provide the capability to restart a program in a different branch of an IF statement?

PREPARING TO TEST (yb_10_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_10_a.ada"

* "yb_10_a.com"

The program yb_10_a consists of five units: the main procedure yb_10_a, the library package specification and body of PACK_DBG10, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_10_a.ada"

Adapt this file to the host operating system:

* "yb_10_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_10_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_10_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_10_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in procedure yb_10_a, line 89 << BREAKPOINT_1 >>. The program will be restarted when BREAKPOINT 1 is reached.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to restart the program from the beginning?

Issue a command to restart the program from the beginning without exiting the debugger. Verify that this breakpoint is still set after restarting the program. Examine X and P10 when this breakpoint is reached after restarting. If variables were reinitialized, X = 1, P10 = 11. If execution was restarted, but variables were not reinitialized, X = 2, P10 = 12. If X = 1, P10 = 12, then variables local to the main procedure were reinitialized, but those in external packages were not. All variables must be reinitialized to pass NUMBER 1.

+ Answer NUMBER 2: Does the debugger provide the capability to restart the program in the ELSE clause of the IF statement? Examine X, then restart at line 85. Examine X to verify that the else clause was executed (X was set to X - 1).

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_11_a: Integration with the Editor

INTRODUCTION: Symbolic Debugger Assessor test yb_11_a tests the debugger interface with an editor.

OVERVIEW OF TEST STEPS (yb_11_a):

Compile and execute test yb_11_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_11_a: Integration with the Editor

1. Does the debugger support an interface with the editor so that the user may enter the editor from the debugger and have the editor cursor positioned in the same place?

After exiting the editor, the debugging session should be resumed at the point where it left off.

2. Does the debugger support an interface with the editor so that the user may enter the editor from the debugger, modify source, recompile, relink, and restart with the new version, with the same set of debugger commands?

PREPARING TO TEST (yb_11_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_11_a.ada"

* "yb_11_a.com"

The program yb_11_a consists of three units: the main procedure yb_11_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_11_a.ada"

Adapt this file to the host operating system:

* "yb_11_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_11_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_11_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_11_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in procedure yb_11_a, line 79 << BREAKPOINT_1 >>. When BREAKPOINT 1 is reached, invoke the editor.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Enter the editor from the debugger and verify that the editor cursor is positioned at the place where the debugger cursor is positioned.

+ Answer NUMBER 2: Enter the editor, modify the source so that the declaration of COLOR1 is "COLOR1: COLOR:= GREEN;" and then recompile and relink the program, and restart with the same set of debugging commands. Verify that the changed source is displayed, and examine COLOR1 to verify that COLOR1 = GREEN.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_12_a: Applicability of the Debugger to Foreign Languages

INTRODUCTION: Symbolic Debugger Assessor test yb_12_a tests the debugger capability to break on return from an assembly language subprogram. Adapted from performance test ms_il_interfac_lang_assem_01.

This problem will have to be adapted to each implementation, using the assembly language of the target. An assembly language procedure in MACRO, the assembly language for the VAX, is provided ("ms_ilnul.mar"). The program uses PRAGMA INTERFACE to call on the procedure, which does a simple return.

If the interface to assembly procedures is not supported by the implementation, or if the problem is not of interest, this test may be skipped. The test may be performed with a procedure written in a different language, if desired.

OVERVIEW OF TEST STEPS (yb_12_a):

Compile and execute test yb_12_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_12_a: Applicability of the Debugger to Foreign Languages

1. Does the debugger provide the capability to break on return from an assembly language subprogram?

PREPARING TO TEST (yb_12_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "ms_ilnul.mar" (or an equivalent assembly language procedure for your processor)

* "yb_12_a.ada"

* "yb_12_a.com"

The program yb_12_a consists of three Ada units: the main procedure yb_12_a, and the library package specification and body of DESCR. A subprogram in another language is also required. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Assemble the file ms_ilnul.mar (or your adapted version).

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_12_a.ada"

Adapt this file to the host operating system:

* "yb_12_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_12_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_12_a):

* Invoke the debugger for yb_12_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set a breakpoint to break on return from procedure ASMNUL. Verify that the breakpoint occurs.

+ Continue execution.

* At BREAKPOINT on return from procedure ASMNUL:

+ Answer NUMBER 1: Does the debugger provide the capability to break on return from assembly language subprogram? Execution should break here (line 75) after execution of procedure ASMNUL.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_12_b: Applicability of the Debugger to Foreign Languages

INTRODUCTION: Symbolic Debugger Assessor test yb_12_b tests the debugger capability to single step through inline machine code (machine code insertions). Not all systems support machine code insertions; this test will be omitted on systems which do not support them. The test must be modified to run on each system. VAX/VMS Ada does not support package MACHINE_CODE. This example was developed under the Telesoft Telegen2 compiler. Each machine code instruction is a record aggregate for a record type defined in the predefined library package MACHINE_CODE.

OVERVIEW OF TEST STEPS (yb_12_b):

Compile and execute test yb_12_b under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_12_b : Applicability of the Debugger to Foreign Languages

1. Does the debugger provide the capability to single step through inline machine code?

PREPARING TO TEST (yb_12_b):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_12_b.ada"

The program yb_12_b consists of three units: the main procedure yb_12_b and the library package specification and body of DESCR. Procedure M_CODE is a machine code insertion procedure. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_12_b.ada"

Adapt these files to the host operating system: (there is no sample command file for this test).

Run this file:

* "yb_12_b.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_12_b):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_12_b.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set a BREAKPOINT 1 at line 102 << BREAKPOINT_1 >>.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to step through inline machine code? Issue a command to step through the statements in the procedure M_CODE. Step through the procedure and then examine WORD_1 and WORD_2.

WORD_1 = 21

WORD_2 = 11

=============================================================

DEBUGGER ASSESSOR TEST yb_13ta: Virtual Calendar (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_13ta will determine whether the debugger uses a "virtual calendar" to ensure that the execution of time critical programs is not altered due to the longer elapsed execution time under the debugger. The virtual calendar would exclude debugger overhead and time spent at breakpoints.

OVERVIEW OF TEST STEPS (yb_13ta):

Compile and execute test yb_13ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_13ta: Virtual Calendar (Tasking)

1. Does the debugger use a virtual calendar in scheduling time critical code?

The program will be run three times.

RUN 1, run the program without the debugger, as a control. The entry call should be accepted.

RUN 2, run the program in the debugger with no breakpoints set. If the call is not accepted, then debugger overhead is interfering with the timing of the entry call.

RUN 3, run the program with two breakpoints set. Enough time will elapse at the first breakpoint to cause the entry call to fail if a virtual calendar is not used. The debugger passes the scenario if the program runs successfully (the entry call is made and accepted) in each case.

The user may want to try the scenario with a delay smaller than 1.0.

PREPARING TO TEST (yb_13ta):

Have these files available:

* "zg_glob1.ada"

* "yb_13ta.ada"

* "yb_13ta.com"

The program yb_13ta consists of three units: the main procedure yb_13ta and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "yb_13ta.ada"

Adapt this file to the host operating system:

* "yb_13ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_13ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_13ta):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_13ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE: Run this test three times.

+ RUN 1, without the debugger. Messages should indicate that the entry call was accepted.

+ RUN 2, under the debugger with no breakpoints set. If the entry call was accepted in RUN 1, but is not accepted in RUN 2, then the debugger is not using a virtual calendar.

+ RUN 3, under the debugger with BREAKPOINTS 1 (line 89 << BREAKPOINT_1 >>) and 2 (line 103) in TAKE_CALL set. Follow the instructions at the breakpoints. If the call is accepted, then a virtual calendar is used.

+ Continue execution.

* At BREAKPOINT 1:

+ Wait a few seconds, then continue execution to the next breakpoint. If a virtual calendar is not used, the DELAY 1.0 will expire, and the call will not be made.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 1: Does the debugger use a virtual calendar in scheduling time critical code? Examine CALL_TAKEN. If CALL_TAKEN = TRUE, then a virtual calendar was used. If CALL_TAKEN = FALSE, then a virtual calendar was not used, and time spent at BREAKPOINT 1 was counted toward the DELAY 1.0.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_14ta: Applicability of the Debugger to Interrupt Handlers (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_14ta tests the applicability of the debugger to an interrupt handler (an Ada task tied to an interrupt). yb_14ta is adapted from performance test tk_in_int_01. This test uses DEC Ada AST (asynchronous system trap) from the package Starlet. To use with a system which actually supports interrupts, two changes will have to be made.

1. Use LOW_LEVEL_IO.SEND_CONTROL to tie the output from the program to an interrupt port. This permits the program to generate an external interrupt. This will replace the entry calls on RECEIVE_AST.

2. An ADDRESS clause must be added to tie the interrupt handler to the interrupt port. (LRM 13.5).

OVERVIEW OF TEST STEPS (yb_14ta):

Compile and execute test yb_14ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_14ta: Applicability of the Debugger to Interrupt Handlers (Tasking)

1. Does the debugger provide the capability to break in an Ada task tied to an interrupt?

2. After breaking in an Ada task tied to an interrupt, is it possible to resume execution?

PREPARING TO TEST (yb_14ta):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_14ta.ada"

* "yb_14ta.com"

The program yb_14ta consists of 3 units: the main procedure yb_14ta and the library package specification and body of DESCR. The main procedure yb_14ta contains two tasks, TIME_TASK, and HANDLE_INT1. TIME_TASK raises an interrupt and tests a flag which is set by the handler, HANDLE_INT1. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_14ta.ada"

Adapt this file to the host operating system:

* "yb_14ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_14ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_14ta):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_14ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in yb_14ta.HANDLE_INT1, line 109 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in yb_14ta.TIME_TASK, line 140 << BREAKPOINT_2 >>. If execution halts at both breakpoints, then NUMBERS 1 and 2 are successful.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to break in an Ada task tied to an interrupt? If the break occurred, then NUMBER 1 is successful.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 2: Resume execution after breakpoint. If this breakpoint was reached, then control returned from the interrupt service routine, and execution was successfully resumed.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_15_a: Conditional Breakpoints

INTRODUCTION: Symbolic Debugger Assessor test yb_15_a tests the debugger conditional breakpoint capability.

OVERVIEW OF TEST STEPS (yb_15_a):

Compile and execute test yb_15_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_15_a: Conditional Breakpoints

1. Does the debugger support a conditional breakpoint which halts execution when one variable becomes greater than another?

2. Does the debugger support a conditional breakpoint which halts execution when a statement is executed for the 5th time?

PREPARING TO TEST (yb_15_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_15_a.ada"

* "yb_15_a.com"

The program yb_15_a consists of three units: the main procedure yb_15_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_15_a.ada"

Adapt this file to the host operating system:

* "yb_15_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_15_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_15_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_15_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 to halt execution when line 72 << BREAKPOINT_1 >> is executed for the 5th time.

+ Set BREAKPOINT 2 to halt execution when INT_1 becomes greater than INT_2.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 2: Does the debugger support a conditional breakpoint which halts when a statement is executed for the 5th time? A break should occur here when the statement is about to be executed for the 5th time. Examine INT_1. INT_1 = 4 at this point.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 1: Does the debugger support a conditional breakpoint which halts when one variable becomes greater than another? A break should occur at the end of the previous line when INT_1 is set to 11, or at the beginning of this line. Examine INT_1 = 11 and INT_2 = 10.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_16_a: Macro Facility

INTRODUCTION: Symbolic Debugger Assessor test yb_16_a tests the debugger's macro facility.

OVERVIEW OF TEST STEPS (yb_16_a):

Compile and execute test yb_16_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_16_a: Macro Facility

1. Can a macro be written to display a set of variables with one command?

2. Can a macro be written to display a set of variables when a breakpoint is taken?

Debugger command files "yb_16_b.com" and "yb_16_c.com" contain the sample macros for the scenario. On some systems, it may be possible to program the debugger to associate a set of actions with a key on the keyboard, rather than using command files.

PREPARING TO TEST (yb_16_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_16_a.ada"

* "yb_16_a.com"

* "yb_16_b.com"

* "yb_16_c.com"

The program yb_16_a consists of three units: the main procedure yb_16_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_16_a.ada"

Adapt this file to the host operating system.

These files are sample VMS command files to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command files. For this scenario it may be necessary to use command files to implement the macros.

* "yb_16_a.com"

* "yb_16_b.com" - Example of MACRO_1.

* "yb_16_c.com" - Example of MACRO_2.

Run this file:

* "yb_16_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_16_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_16_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Two macros must be prepared for this test:

MACRO_1 will display the values of A_1, A_2, and A_3.

MACRO_2 will display the values of INT_1, REAL_1, and ARRAY_1.

+ Set BREAKPOINT 1 in procedure A, line 82 << BREAKPOINT_1 >>. When the breakpoint is reached, issue one command to invoke MACRO_1 to display a set of variables.

+ Set BREAKPOINT 2 in yb_16_a, line 101 << BREAKPOINT_2 >>, so that MACRO_2 to display a set of variables is automatically invoked at the breakpoint.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Can a macro be written to display a set of variables with one command? Invoke a macro to display these variables:

A_1 = 3

A_2 = 1.15010

A_3 = (1..10 => 1,2,3,4,5,6,7,8,9,10)

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 2: Can a macro be written to display a set of variables when a breakpoint is taken? These variables should be displayed:

INT_1 = 4

REAL_1 = 1.15010

ARRAY_1 = (1..10 => 2,3,4,5,6,7,8,9,10,11)

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_17_a: Log File (Tracing)

INTRODUCTION: Symbolic Debugger Assessor test yb_17_a tests the logging of debugger output to a file.

OVERVIEW OF TEST STEPS (yb_17_a):

Compile and execute test yb_17_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_17_a: Log File (Tracing)

1. Does the debugger support logging debugger output to a file for later analysis? The commands issued and the debugger output should be logged.

PREPARING TO TEST (yb_17_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_17_a.ada"

* "yb_17_a.com"

The program yb_17_a consists of three units: the main procedure yb_17_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_17_a.ada"

Adapt this file to the host operating system:

* "yb_17_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_17_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_17_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_17_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Issue a command to log debugger output.

+ Set BREAKPOINT 1 in yb_17_a, line 76 << BREAKPOINT_1 >>. Follow the instructions when the breakpoint is reached. Verify that the breakpoint, the commands issued, and the debugger output are correctly logged. The emphasis in this scenario is not on the commands issued, but on accurate logging of the commands and responses. Verify that the output from supported commands is logged correctly.

+ Continue execution.

* At BREAKPOINT 1:

+ The line number and compilation unit where the breakpoint occurred should be logged.

+ Set a watchpoint on REAL_1. The command issued should be logged.

+ Single step through the next six instructions. The compilation unit and line numbers stepped to should be logged.

+ Examine RECORD_1. The value displayed should be logged.

RECORD_1.STR = "zyxwvutsrq"

RECORD_1.B = TRUE

RECORD_1.X = 0.49991

RECORD_1.I = 10

RECORD_1.J = 1

RECORD_1.C = YELLOW

+ Continue execution.

* At WATCHPOINT 1, on REAL_1 (line 105):

+ The previous statement changes the value of variable REAL_1. Verify that the line number and compilation unit of the break are logged, as well as the value of REAL_1.

Old value of REAL_1 = 1.15010.

New value of REAL_1 = 2.15010.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_18_a : Isolation of Debugger I/O

INTRODUCTION: Symbolic Debugger Assessor test yb_18_a tests the isolation of debugger input and output. The program will perform console input and output, which should be clearly distinguished from the debugger input and output.

OVERVIEW OF TEST STEPS (yb_18_a):

Compile and execute test yb_18_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_18_a: Isolation of Debugger I/O

1. Is debugger input and output clearly distinguished from program input and output?

PREPARING TO TEST (yb_18_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_18_a.ada"

* "yb_18_a.com"

The program yb_18_a consists of three units: the main procedure yb_18_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_18_a.ada"

Adapt this file to the host operating system:

* "yb_18_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_18_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_18_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_18_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

This program will perform console input and output. You will be prompted to enter a string, an INTEGER16 number, and a FLOAT6 number. The debugger passes the scenario if the debugger input and output is isolated, using windows or some other technique, from the program input and output. Debugger input should be clearly distinguished from program input, and debugger output should be clearly distinguished from program output.

+ Set BREAKPOINT 1 in yb_18_a, line 135 << BREAKPOINT_1 >>.

+ Set BREAKPOINT 2 in yb_18_a, line 146 << BREAKPOINT_2 >>.

+ Set BREAKPOINT 3 in yb_18_a, line 161 << BREAKPOINT_3 >>.

+ Continue execution.

* At BREAKPOINT 1:

+ Examine C_1. The value output by the debugger should not be mixed in with the text output by the program. C_1 = YELLOW.

+ Continue execution.

* At BREAKPOINT 2:

+ Examine STRING_PTR.ALL. The debugger response should be distinguished from the program output of the same value performed by the line above.

+ Continue execution.

* At BREAKPOINT 3:

+ Examine R_1. The debugger response should be distinguished from the program output of the same value performed by the lines above.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_19_a: Access to Machine Properties

INTRODUCTION: Symbolic Debugger Assessor test yb_19_a tests the debugger capability to access machine properties.

OVERVIEW OF TEST STEPS (yb_19_a):

Compile and execute test yb_19_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_19_a: Access to Machine Properties:

1. Does the debugger provide the capability to examine machine registers?

2. Does the debugger provide the capability to step by machine instructions?

PREPARING TO TEST (yb_19_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_19_a.ada"

* "yb_19_a.com"

The program yb_19_a consists of three units: the main procedure yb_19_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_19_a.ada"

Adapt this file to the host operating system:

* "yb_19_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_19_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_19_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_19_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 at line 70 << BREAKPOINT_1 >> of main procedure yb_19_a.

At the breakpoint, issue commands to single step through the next three statements by machine instruction. Display the registers after each step.

+ Continue execution.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to single step by machine instructions?

+ Answer NUMBER 2: Does the debugger provide the capability to examine machine registers?

Single step by instruction through this statement and the next two, examining the registers at each step. It may be possible to define a macro to step one instruction and display registers.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_20_a: Isolate Exception

INTRODUCTION: Symbolic Debugger Assessor test yb_20_a tests the debugger capability to isolate the statement which raised a predefined or a specific user-defined exception. yb_20ta tests the debugger capability to isolate the statement raising a TASKING_ERROR.

OVERVIEW OF TEST STEPS (yb_20_a):

Compile and execute test yb_20_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order, because preconditions must sometimes be established.

yb_20_a: Isolate Exception

1. Does the debugger provide the capability to break on any exception raised?

The debugger must halt execution on four exceptions: a user-defined exception USER_ERROR, CONSTRAINT_ERROR, STORAGE_ERROR, and PROGRAM_ERROR. It is preferable to break on the statement which raised the exception, but breaking in the handler is also acceptable. (See NUMBER 6)

2. Does the debugger provide the capability to break on a specific user-defined exception?

3. Does the debugger provide the capability to break on a range constraint violation?

4. Does the debugger provide the capability to break on a storage error?

5. Does the debugger provide the capability to break on a program error?

6. Did the breaks occur on the statement raising the exception, or only in handler?

PREPARING TO TEST (yb_20_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_20_a.ada"

* "yb_20_a.com"

The program yb_20_a consists of 5 units: the main procedure yb_20_a, the library package specification and body of PACK_DBG20, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_20_a.ada"

Adapt this file to the host operating system:

* "yb_20_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_20_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_20_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_20_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 at line 201 << BREAKPOINT_1 >> of main procedure yb_20_a. Follow instructions at each breakpoint.

+ Continue execution.

* At BREAKPOINT 1:

+ Set BREAKPOINT 6 at line 236 << BREAKPOINT_6 >>.

+ Set BREAKPOINT 8 at line 248 << BREAKPOINT_8 >>.

+ Set BREAKPOINT 10 at line 260 << BREAKPOINT_10 >>.

+ Set BREAKPOINT 12 at line 268 << BREAKPOINT_12 >>.

+ Set a breakpoint which will halt execution when any exception is raised. Four procedures will be called; each will raise an exception. BREAKPOINTS 2, 3, 4, and 5 should occur in the procedures.

+ Continue execution.

* At BREAKPOINT 2:

+ Answer NUMBER 1: Capability to break on any exception raised. This is the first of four breaks which must occur to pass NUMBER 1.

+ Continue to the next breakpoint.

* At BREAKPOINT 3:

+ Answer NUMBER 1: Capability to break on any exception raised. This is the second of four breaks which must occur to pass NUMBER 1.

+ Continue to the next breakpoint.

* At BREAKPOINT 4:

+ Answer NUMBER 1: Capability to break on any exception raised. This is the third of four breaks which must occur to pass NUMBER 1.

+ Continue to the next breakpoint.

* At BREAKPOINT 5:

(This exception is caused by the lack of an executable return statement, so the line number for this breakpoint is approximate.)

+ Answer NUMBER 1: Capability to break on any exception raised. This is the last of four breaks which must occur to pass NUMBER 1. If BREAKPOINTS 2, 3, 4, and 5 occurred as indicated, or in the handlers, then NUMBER 1 is successful. If some or all of the breaks occurred in the handlers, note this in NUMBER 6.

+ Continue to the next breakpoint.

* At BREAKPOINT 6:

+ Cancel the breakpoint on any exception which was set above.

+ Set a breakpoint to halt execution when user-defined exception USER_ERROR is raised.

+ Continue to the next breakpoint.

* At BREAKPOINT 7:

+ Answer NUMBER 2: Capability to break on a specific user-defined exception. NUMBER 2 is successful if the break occurs here or in the handler. If the break occurs in the handler, note this in NUMBER 6.

+ Continue to the next breakpoint.

* At BREAKPOINT 8:

+ Set a breakpoint to halt execution when exception CONSTRAINT_ERROR is raised.

+ Continue to the next breakpoint.

* At BREAKPOINT 9:

+ Answer NUMBER 3: Capability to break on a CONSTRAINT_ERROR exception. NUMBER 3 is successful if the break occurs here or in the handler. If the break occurs in the handler, note this in NUMBER 6.

+ Continue to the next breakpoint.

* At BREAKPOINT 10:

+ Set a breakpoint to halt execution when exception STORAGE_ERROR is raised.

+ Continue to the next breakpoint.

* At BREAKPOINT 11:

+ Answer NUMBER 4: Capability to break on a STORAGE_ERROR exception. NUMBER 4 is successful if the break occurs here or in the handler. If the break occurs in the handler, note this in NUMBER 6.

+ Continue to the next breakpoint.

* At BREAKPOINT 12:

+ Set a breakpoint to halt execution when exception PROGRAM_ERROR is raised.

+ Continue to the next breakpoint.

* At BREAKPOINT 13:

+ Answer NUMBER 5: Capability to break on a PROGRAM_ERROR exception. NUMBER 5 is successful if the break occurs here or in the handler. If the break occurs in the handler, note this in NUMBER 6. BREAKPOINT 13 is the last breakpoint.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_20ta: Isolate Exception (Tasking)

INTRODUCTION: Symbolic Debugger Assessor test yb_20ta tests the debugger capability to isolate the statement which raised a TASKING_ERROR exception. yb_20ta is adapted from performance test tk_lb_task_38. Test yb_20_a tests the debugger capability to isolate a statement which raised a non-tasking exception.

OVERVIEW OF TEST STEPS (yb_20ta):

Compile and execute test yb_20ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_20ta: Isolate Exception (Tasking)

1. Does the debugger provide the capability to break on a TASKING_ERROR exception?

2. Did the break occur on the statement raising the exception, or only in handler?

PREPARING TO TEST (yb_20ta):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_20ta.ada"

* "yb_20ta.com"

The program yb_20ta consists of 5 units: the main procedure yb_20ta, the library package specification and body of PACK_DBG20_T, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_20ta.ada"

Adapt this file to the host operating system:

* "yb_20ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_20ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_20ta):

* Invoke the debugger for yb_20ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 to halt execution when exception TASKING_ERROR is raised. Follow the instructions at BREAKPOINT 1.

+ Continue to the next breakpoint.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to break on exception TASKING_ERROR? NUMBER 1 is successful if the break occurs here or in the handler.

+ Answer NUMBER 2: Did the break occur at the statement raising the exception, or only in the handler?

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_21ta: Non-terminating Tasks

INTRODUCTION: Symbolic Debugger Assessor test yb_21ta tests the debugger capability to provide information about non-terminating tasks. The debugger should be able to list the tasks created by a subprogram, and the status of each task, and to list all tasks in a program and their status and parent. This test is adapted from performance test tk_lf_task_02.

OVERVIEW OF TEST STEPS (yb_21ta):

Compile and execute test yb_21ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

The template questions may not be answered in order because preconditions must sometimes be established.

yb_21ta: Non-terminating Tasks

1. Does the debugger provide the capability to list all tasks created by a subprogram, and the status of each task?

2. Does the debugger provide the capability to list all the tasks in a program, and identify the parent and status of each task?

PREPARING TO TEST (yb_21ta):

Have these files available:

* "zg_glob1.ada"

* "yb_21ta.ada"

* "yb_21ta.com"

The program yb_21ta consists of three units: the main procedure yb_21ta, and the library package specification and body of DESCR. Procedure TASKING in yb_21ta will create four non-terminating tasks. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "yb_21ta.ada"

Adapt this file to the host operating system:

* "yb_21ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_21ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_21ta):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_21ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set BREAKPOINT 1 in the body of SIMPLE_TASK, line 81 << BREAKPOINT_1 >>. At the breakpoint, issue a command to list all the tasks created by procedure TASKING, and all tasks in the program. Then exit the debugger (the program will not terminate).

+ Continue to the next breakpoint.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to list all tasks created by a subprogram, and the status of each task?

Issue a command to list all tasks created by procedure TASKING, and the status of each of these tasks. Tasks T1, T2, T3, and T4 have been created by TASKING; one of them is running, and the other three are ready.

+ Answer NUMBER 2: Does the debugger provide the capability to list all the tasks in a program, and identify the parent and status of each task?

Issue a command to list all the tasks in the program, and the status and parent of each task. The tasks are: the main program task, yb_21ta, status = READY, and tasks T1, T2, T3, and T4. One of T1, T2, T3, and T4 is running, and the other three are ready; the parent is procedure TASKING in main program task yb_21ta.

+ Exit the debugger; the program will not terminate.

=============================================================

DEBUGGER ASSESSOR TEST yb_22_a: Break on Failure in a Declarative Region

INTRODUCTION: Symbolic Debugger Assessor test yb_22_a tests the debugger capability to break on an exception raised in a declarative region.

OVERVIEW OF TEST STEPS (yb_22_a):

Compile and execute test yb_22_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_22_a: Break on Failure in a Declarative Region

1. Does the debugger provide the capability to break on an exception raised in a declarative region?

PREPARING TO TEST (yb_22_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_22_a.ada"

* "yb_22_a.com"

The program yb_22_a consists of three units: the main procedure yb_22_a, and the library package specification and body of DESCR. Procedure DECLARATIVE_ERROR in yb_22_a will raise an exception during elaboration of its declarative region. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_22_a.ada"

Adapt this file to the host operating system:

* "yb_22_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_22_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_22_a):

* Invoke the debugger for yb_22_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set a breakpoint which will break on any exception, or on exception CONSTRAINT_ERROR. BREAKPOINT 1 should occur when procedure DECLARATIVE_ERROR raises a CONSTRAINT_ERROR during elaboration of its declarative region. Verify that the break occurs on the statement raising the exception.

+ Continue to the next breakpoint.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to break on an exception raised in a declarative region? This statement will raise a CONSTRAINT_ERROR. The break must occur in the declarative region to pass NUMBER 1.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_23_a: Break on Failure in Library Package Body Initialization

INTRODUCTION: Symbolic Debugger Assessor test yb_23_a tests the debugger capability to break on an exception raised in a library package body.

OVERVIEW OF TEST STEPS (yb_23_a):

Compile and execute test yb_23_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_23_a: Break on Failure in Library Package Body Initialization

1. Does the debugger provide the capability to break on an exception raised in a library package body?

PREPARING TO TEST (yb_23_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_23_a.ada"

* "yb_23_a.com"

The program yb_23_a consists of five units: the main procedure yb_23_a, the library package specification and body of PACK_DBG23, and the library package specification and body of DESCR. The body of package PACK_DBG23 will raise an exception during package body initializations. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_23_a.ada"

Adapt this file to the host operating system:

* "yb_23_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_23_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_23_a):

* Invoke the debugger for yb_23_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Set a breakpoint to break when any exception is raised, or when exception NUMERIC_ERROR is raised. BREAKPOINT 1 should occur when package body PACK_DBG23 raises a NUMERIC_ERROR during package body initializations. Verify that the break occurs at the package body statement raising the exception.

+ Continue to the next breakpoint.

* At BREAKPOINT 1:

+ Answer NUMBER 1: Does the debugger provide the capability to break on an exception raised in a library package body? This statement will raise exception NUMERIC_ERROR when attempting to divide by zero. The break must occur here to successfully complete NUMBER 1.

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_24_a: Library Package Elaboration Order

INTRODUCTION: Symbolic Debugger Assessor test yb_24_a tests the debugger capability to provide information on the library package elaboration order.

OVERVIEW OF TEST STEPS (yb_24_a):

Compile and execute test yb_24_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_24_a: Library Package Elaboration Order

1. Can the debugger be used to determine the library package elaboration order?

To pass the scenario, breaks must occur on the library package specification and body of PACK_D24_A, PACK_D24_B, and PACK_D24_C, and EXCH_INT.

It may be possible to set breakpoints on the specification and body of generic unit PACK_EXCHANGE which would be triggered when an instantiation is elaborated, but this is not necessary to pass the scenario.

Both the specification and body of PACK_D24_A must be elaborated before the specification of PACK_D24_B, and the specification and body of PACK_D24_B must be elaborated before the main procedure yb_24_a. The specification and body of PACK_D24_C and EXCH_INT will be elaborated with the other declarations in yb_24_a.

PREPARING TO TEST (yb_24_a ):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_24_a.ada"

* "yb_24_a.com"

The program yb_24_a consists of 11 units: the main procedure yb_24_a, the library package specifications and bodies of PACK_D24_A, PACK_D24_B, PACK_D24_C, and EXCH_INT, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_24_a.ada"

Adapt this file to the host operating system:

* "yb_24_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_24_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_24_a ):

* Invoke the debugger for yb_24_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Determine the library package elaboration order by setting breakpoints on library package specifications and bodies, and recording the order of the elaboration. Set breakpoints on specification and body of PACK_D24_A, PACK_D24_B, PACK_D24_C, and generic instantiation EXCH_INT.

+ Answer NUMBER 1: Can the debugger be used to determine the library package elaboration order?

+ Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_25_a: Execution Time Degradation by Debugger

INTRODUCTION: Symbolic Debugger Assessor test yb_25_a tests execution time degradation under the debugger. This test is adapted from performance test cl_wh_whet_01. Modifications to the program (adding package DESCR and a call on function DESCRIBE) were made outside the timing loop, so that the timed code in program yb_25_a is identical to the timed code in cl_wh_whet_0.

OVERVIEW OF TEST STEPS (yb_25_a):

Compile and execute test yb_25_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_25_a: Execution Time Degradation by Debugger

1. Elapsed execution time of performance test cl_wh_whet_01?

Record the minimum (or mean) elapsed execution time collected for the performance test cl_wh_whet_01. The minimum execution time can be found in the test suite output file, or in the raw data report output by Comparative Analysis (CA). This value can be compared with the elapsed execution times collected under the debugger to determine how much performance degradation occurs when a program is run under the debugger.

2. Elapsed execution time with no breakpoints or watchpoints set?

3. Elapsed execution time with watchpoints set on several variables whose values change frequently?

Watchpoints may decrease performance substantially, especially if the variable is nonstatic, and if the value of the variable is checked after each statement. If execution continues for an excessive amount of time (20 minutes, or your threshold of pain), you may interrupt the program and note the time and the fact that execution was interrupted.

4. Elapsed execution time with breakpoints set on exceptions which are not raised?

5. Elapsed execution time with several breakpoints set but never taken?

The program will be executed four times under the debugger. In each of the four runs, the program should run completely through without breaking inside the timing loop. Compare the elapsed execution time collected for the performance test with the elapsed execution times collected under the debugger.

PREPARING TO TEST (yb_25_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob2.ada"

* "zg_glob3.*" Where the wild-card character "*" represents the subset ".ell", ".elg", ".cpy", or ".cpg" (see the Pretest).

* "zg_glob4.ada"

* "zg_cpy.db"

* "zg_incld.*" Where "*" is ".ell", ".elg", ".cpy", or ".cpg" (see the Pretest).

* "zg_start.*" Where "*" is ".ell", ".elg", ".cpy", or ".cpg" (see the Pretest).

* "zg_stop0.*" Where "*" is ".ell", ".elg", ".cpy", or ".cpg" (see the Pretest).

* "zg_stop2.*" Where "*" is ".ell," ".elg", ".cpy", or ".cpg" (see the Pretest).

* "zg_verfy.*" Where "*" is ".ell", ".elg", ".cpy", or ".cpg" (see the Pretest).

* "zm_math.*" Where "*" is ".ada", ".por", or ".dec" (see the Pretest).

* "yb_25_a.inc"

* "yb_25_a.com"

The program yb_25_a consists of three units: the main procedure yb_25_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob2.ada"

* "zg_glob3.*" Where "*" is ".ell", ".elg", ".cpy", or ".cpg" (see the Pretest).

* "zg_glob4.ada"

* "zm_math.*" Where "*" is ".ada", ".por", or ".dec" (see the Pretest).

* "yb_25_a.ada" - NOTE: yb_cmp1.com will include timing loop code in "yb_25_a.inc", compile and link "yb_25_a.ada".

Adapt this file to the host operating system:

* "yb_25_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Before this test is run the user may wish to consider redirecting the output (which goes to standard output) to a file. This step is helpful if the debugger under examination does not cleanly separate its output from the program output. The sample command file for compiling the programs ("yb_cmp1.com") performs this step for DEC systems.

Run this file:

* "yb_25_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_25_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_25_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

Execute this program 4 times under the debugger, and record the mean execution time for each run. If the program runs for an excessive amount of time you may terminate it manually. Some debuggers are very slow, particularly when watchpoints are set. The program may print a message saying the verification of the timing loop parameters failed. Do not be concerned. This message is irrelevant for these measurements.

+ FIRST RUN: no breakpoints or watchpoints set. Continue execution to end of program.

+ SECOND RUN:

- Set a preliminary breakpoint outside the timing loop at label

<< BREAKPOINT_0 >>.

- At that breakpoint:

Set a watchpoint on ZG_GLOB1.ZERO (in package, static).

Set a watchpoint to break when yb_25_a.K = 4.

Set a watchpoint to break when yb_25_a.L = 4.

Note: that K and L will be assigned to more than 2100 times. Performance may decrease substantially.

- Continue execution to end of program.

+ THIRD RUN:

- Set breakpoints on exceptions NUMERIC_ERROR, PROGRAM_ERROR, and STORAGE_ERROR.

- Continue execution to end of program.

+ FOURTH RUN:

- Set breakpoint on the line labeled << BREAKPOINT_1 >>.

- Set breakpoint on the line labeled << BREAKPOINT_2 >>.

- Set breakpoint on the line labeled << BREAKPOINT_3 >>.

Note: These lines may be optimized away. If this happens, either recompile without optimization, or skip this problem. The purpose of the Fourth Run is to observe the effect of setting breakpoints on lines that are not executed. A good optimizing compiler may not leave any such lines.

- Set a breakpoint to break on PA, after 1000 calls (increase if a break occurs).

- Continue execution to end of program.

=============================================================

DEBUGGER ASSESSOR TEST yb_26ta: Task Deadlock

INTRODUCTION: Symbolic Debugger Assessor test yb_26ta tests the debugger capability to inform the user of task deadlock, and to allow examination of the state of each task.

OVERVIEW OF TEST STEPS (yb_26ta):

Compile and execute test yb_26ta under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_26ta: Task Deadlock

1. Does the debugger regain control when all tasks deadlock, and allow examination of the state of each task, including the entry call on which it is waiting?

PREPARING TO TEST (yb_26ta):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_26ta.ada"

* "yb_26ta.com"

The program yb_26ta consists of three units: the main procedure yb_26ta, and the library package specification and body of DESCR. Procedure TASKLOCK in yb_26ta will create three tasks, which will immediately deadlock. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_26ta.ada"

Adapt this file to the host operating system:

* "yb_26ta.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_26ta.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_26ta):

* Invoke the debugger for yb_26ta.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Continue execution. Tasks TASK_A, TASK_B, and TASK_C in procedure TASKLOCK will deadlock, while main procedure yb_26ta waits on dependents. Determine whether the debugger can detect the deadlock, regain control, and issue a message informing the user that there are no runnable tasks. If the debugger does not regain control, interrupt execution. Issue a command to display the state of each task, including the entry call on which it is waiting. The code segment below shows the entry calls made.



task TASK_A is -- When deadlock occurs,


pragma PRIORITY (ZG_GLOB1.PRIORITY_1); -- TASK_A will be waiting entry

ENTRY_A; -- on an entry call to

end TASK_A; -- ENTRY_B.



task TASK_B is -- When deadlock occurs,


pragma PRIORITY (ZG_GLOB1.PRIORITY_2); -- TASK_B will be waiting entry


ENTRY_B; -- on an entry call to

end TASK_B; -- ENTRY_C.

task TASK_C is -- When deadlock occurs,

pragma PRIORITY (ZG_GLOB1.PRIORITY_3); -- TASK_C will be waiting entry

ENTRY_C; -- on an entry call to

end TASK_C; -- ENTRY_A.


TASKLOCK; -- When deadlock occurs, main program task



-- will be waiting on dependents.



+ Answer NUMBER 1: Does the debugger regain control when all tasks deadlock, and allow examination of the state of each task, including the entry call on which it is waiting?

+ Exit the debugger.

=============================================================

DEBUGGER ASSESSOR TEST yb_27_a: Limits on the Number of Breakpoints

INTRODUCTION: Symbolic Debugger Assessor test yb_27_a tests the limits on the number of breakpoints allowed. Adapted from several ACES performance tests.

OVERVIEW OF TEST STEPS (yb_27_a):

Compile and execute test yb_27_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_27_a: Limits on the Number of Breakpoints

1. Are 10 breakpoints allowed?

2. Are 30 breakpoints allowed?

3. Are 50 breakpoints allowed?

The program will be run three times, the first time with 10 breakpoints set, the second time with 30 breakpoints set, and the third time with 50 breakpoints set. It may be helpful to mark each breakpoint off on a listing as it is performed. If a particular breakpoint is not supported (break on exception, for example), choose another breakpoint. The emphasis is on the number of breakpoints in effect.

PREPARING TO TEST (yb_27_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_27_a.ada"

* "yb_27_a.com"

The program yb_27_a consists of three units: the main procedure yb_27_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_27_a.ada"

Adapt this file to the host operating system:

* "yb_27_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_27_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_27_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_27_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE: This program will be run under the debugger three times, with different numbers of breakpoints set. This is BREAKPOINT 1.

+ Set BREAKPOINT 2 at the beginning of yb_27_a, line 209 << BREAKPOINT_2 >>.

+ RUN 1: Execute the program with BREAKPOINTS 1 - 10 set. Verify that all are taken.

+ RUN 2: Execute the program with BREAKPOINTS 1 - 30 set. Verify that all are taken.

+ RUN 3: Execute the program with BREAKPOINTS 1 - 50 set. Verify that all are taken.

+ Continue execution. Set breakpoints as instructed.

* At BREAKPOINT 2:

Set BREAKPOINT 3 at line 283 << BREAKPOINT_3 >>.

Set BREAKPOINT 4 at line 288 << BREAKPOINT_4 >>.

Set BREAKPOINT 5 at line 296 << BREAKPOINT_5 >>.

Set BREAKPOINT 6 on PROGRAM_ERROR.

Set BREAKPOINT 7 at line 303 << BREAKPOINT_7 >>.

Set BREAKPOINT 8 at line 304 << BREAKPOINT_8 >>.

Set BREAKPOINT 9 at line 305 << BREAKPOINT_9 >>.

Set BREAKPOINT 10 at line 308 << BREAKPOINT_10 >>.

+ Answer NUMBER 1: Does the debugger allow ten breakpoints to be set at one time? Continue execution and verify that each of the ten breakpoints is taken. Then exit or restart the debugger for the next run.

Set BREAKPOINT 11 on procedure P_IN.

Set BREAKPOINT 12 at line 140 of P_IN << BREAKPOINT_12 >>.

Set BREAKPOINT 13 at line 309 << BREAKPOINT_13 >>.

Set BREAKPOINT 14 on procedure P_OUT.

Set BREAKPOINT 15 at line 147 of P_OUT << BREAKPOINT_15 >>.

Set BREAKPOINT 16 at line 310 << BREAKPOINT_16 >>.

Set BREAKPOINT 17 on procedure P_INOUT.

Set BREAKPOINT 18 at line 155 of P_INOUT << BREAKPOINT_18 >>.

Set BREAKPOINT 19 at line 313 << BREAKPOINT_19 >>.

Set BREAKPOINT 20 on procedure MAX1.

Set BREAKPOINT 21 at line 99 of MAX1 << BREAKPOINT_21 >>.

Set BREAKPOINT 22 at line 315 << BREAKPOINT_22 >>.

Set BREAKPOINT 23 on procedure MIN1.

Set BREAKPOINT 24 at line 110 of MIN1 << BREAKPOINT_24 >>.

Set BREAKPOINT 25 at line 321 << BREAKPOINT_25 >>.

Set BREAKPOINT 26 at line 327 << BREAKPOINT_26 >>.

Set BREAKPOINT 27 at on function CHECK_SORT.

Set BREAKPOINT 28 at line 203 in CHECK_SORT << BREAKPOINT_28 >>.

Set BREAKPOINT 29 at line 331 << BREAKPOINT_29 >>.

Set BREAKPOINT 30 on procedure DIFF.

+ Answer NUMBER 2: Does the debugger allow 30 breakpoints to be set at one time? Continue execution and verify that each of the thirty breakpoints is taken. Then exit or restart the debugger for the next run.

Set BREAKPOINT 31 at line 171 in FUNC << BREAKPOINT_31 >>.

Set BREAKPOINT 32 at line 332 << BREAKPOINT_32 >>.

Set BREAKPOINT 33 at line 335 << BREAKPOINT_33 >>.

Set BREAKPOINT 34 on function NEG.

Set BREAKPOINT 35 at line 119 in NEG << BREAKPOINT_35 >>.

Set BREAKPOINT 36 on CONSTRAINT_ERROR.

Set BREAKPOINT 37 at line 341 << BREAKPOINT_37 >>.

Set BREAKPOINT 38 at line 343 << BREAKPOINT_38 >>.

Set BREAKPOINT 39 on function ABSO.

Set BREAKPOINT 40 at line 132 in ABSO << BREAKPOINT_40 >>.

Set BREAKPOINT 41 at line 345 << BREAKPOINT_41 >>.

Set BREAKPOINT 42 on procedure NEXT_COLOR.

Set BREAKPOINT 43 at line 183 in NEXT_COLOR << BREAKPOINT_43 >>.

Set BREAKPOINT 44 at line 346 << BREAKPOINT_44 >>.

Set BREAKPOINT 45 at line 347 << BREAKPOINT_45 >>.

Set BREAKPOINT 46 on function PLUS_TEN.

Set BREAKPOINT 47 at line 181 in PLUS_TEN << BREAKPOINT_47 >>.

Set BREAKPOINT 48 at line 348 << BREAKPOINT_48 >>.

Set BREAKPOINT 49 at line 350 << BREAKPOINT_49 >>.

Set BREAKPOINT 50 at line 351 << BREAKPOINT_50 >>.

+ Answer NUMBER 3: Does the debugger allow 50 breakpoints to be set at one time? Continue execution and verify that each of the fifty breakpoints is taken.

=============================================================

DEBUGGER ASSESSOR TEST yb_28_a: Program Termination

INTRODUCTION: Symbolic Debugger Assessor test yb_28_a tests the capability to treat program termination as an implicit breakpoint.

OVERVIEW OF TEST STEPS (yb_28_a):

Compile and execute test yb_28_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_28_a: Program Termination

1. Is program termination treated as an implicit breakpoint?

PREPARING TO TEST (yb_28_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_28_a.ada"

* "yb_28_a.com"

The program yb_28_a consists of five units: the main procedure yb_28_a, the library package specification and body of PACK_28, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_28_a.ada"

Adapt this file to the host operating system:

* "yb_28_a.com" - A sample VMS command file to show the steps to be entered in the debugger. It is more informative to enter the commands interactively than to execute the command file.

Run this file:

* "yb_28_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_28_a):

* Invoke the debugger for yb_28_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE: Continue execution. At program termination, the last line of the program should be displayed, and it should be possible to examine the values of variables. At the end of the program, examine the variables INT_1, X(1), X(50), M, and N.

* At IMPLICIT BREAKPOINT AT TERMINATION: Answer NUMBER 1: Is program termination treated as an implicit breakpoint? Examine these variables:

INT_1 = 0

X(1) = 0.9995

X(50) = -10000000000

M = 50

N = 101

=============================================================

DEBUGGER ASSESSOR TEST yb_29_a: Debugger Command Files

INTRODUCTION: Symbolic Debugger Assessor test yb_29_a tests the debugger command file capability. Adapted from performance test dr_tc_type_char_02.

OVERVIEW OF TEST STEPS (yb_29_a):

Compile and execute test yb_29_a under the debugger. Answer the following questions and record the results on the Symbolic Debugger Assessor Summary Report.

yb_29_a: Debugger Command Files

1. Does the debugger support debugger command files?

This test requires that a debugger command file be prepared. The command file will be invoked at the breakpoint in DESCRIBE. An example is provided in "yb_29_b.com". The command file should issue commands to perform the following operations: Set BREAKPOINT 1 in yb_29_a at line 87 and continue execution to BREAKPOINT 1. At BREAKPOINT 1, set BREAKPOINT 2 at line 94, and BREAKPOINT 3 at line 106, and continue execution to BREAKPOINT 2. BREAKPOINT 2 will be taken three times; display INT_1, CHAR, and STRING10 each time, and continue execution to BREAKPOINT 3. Exit command file.

PREPARING TO TEST (yb_29_a):

Have these files available:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_29_a.ada"

* "yb_29_a.com"

* "yb_29_b.com"

The program yb_29_a consists of three units: the main procedure yb_29_a, and the library package specification and body of DESCR. DESCR is a package included in each Symbolic Debugger program; it contains a function DESCRIBE which contains comments describing the scenario.

Compile these files:

* "zg_glob1.ada"

* "zg_glob4.ada"

* "yb_29_a.ada"

Adapt these files to the host operating system :

These files are sample VMS command files to show the steps to be entered in the debugger. The commands in yb_29_a may be entered interactively, but "yb_29_b.com" must be adapted since this is a test of debugger command files.

* "yb_29_a.com"

* "yb_29_b.com"

Run this file:

* "yb_29_a.exe" - Invoke under the debugger.

EXECUTING THE TEST (yb_29_a):

Breakpoints are given by line number, and where appropriate, by label. Label names are always "BREAKPOINT_nn", where "nn" is the breakpoint number. Breakpoints can be set either by line number or by label, where available.

* Invoke the debugger for yb_29_a.

* Set a breakpoint on the function DESCRIBE, and go to that breakpoint.

* At BREAKPOINT on DESCRIBE:

+ Invoke a debugger command file (see the example in "yb_29_b.com") to perform these operations:

- Set BREAKPOINT 1 in yb_29_a at line 87 << BREAKPOINT_1 >>.

- Continue execution to BREAKPOINT 1.

- At BREAKPOINT 1:

Set BREAKPOINT 2 at line 94 << BREAKPOINT_2 >>. Set BREAKPOINT 3 at line 106 << BREAKPOINT_3 >>.

- Continue execution to BREAKPOINT 2. BREAKPOINT 2 will be taken three times; Display INT_1, CHAR, and STRING10 each time, and continue execution to BREAKPOINT 3.

- Exit command file. The debugger should be halted at BREAKPOINT 3 when control returns to the command line. Follow instructions at BREAKPOINT 3.

* (Performed by the debugger command file) At BREAKPOINT 1:

+ Set BREAKPOINT 2 at line 94 << BREAKPOINT_2 >>.

+ Set BREAKPOINT 3 at line 106 << BREAKPOINT_3 >>.

+ Continue to the next breakpoint.

* (Performed by the debugger command file) At BREAKPOINT 2 (three times):

+ Examine INT_1, CHAR, and STRING10.

INT_1 = 1,5,9.

CHAR = 'A','E','I'.

STRING10 = "*BCDEFGHIJ", "*BCD*FGHIJ", "*BCD*FGH*J".

+ Continue to the next breakpoint.

* At BREAKPOINT 3:

+ Answer NUMBER 1: Does the debugger support debugger command files? Verify that the commands in the debugger command file were performed correctly. After exiting the command file, the debugger should accept interactive commands.

Examine INT_1

INT_1 = 11

+ Continue execution to end of program.

ADA COMPILER EVALUATION SYSTEM Version 2.0

SYMBOLIC DEBUGGER ASSESSOR REPORT

Evaluator's Name:_______________________________________Date:___________

Host

Compiler:_______________________________________________Version:________

Host

Operating

System:_________________________________________________Version:________

Host

Hardware:_______________________________________________Model:__________

System

Memory:_________

Target

Hardware:_______________________________________________Model:__________

System

Memory:_________

Compilation options used to enable debugging:___________________________

Other

Information:____________________________________________________________

========================================================================

========================================================================

Y / N / P column - Fill in with Y: Yes - succeeded

P: Partial

N: No - failed or not supported

COMMAND line - Fill in with the command used (or attempted).

Add more lines as necessary.

(Time) - Replace with time measurement.

========================================================================

SCENARIO Y/N/P

1. System State Information

YB_01_A

1.Identify next statement to execute : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Display main program task time : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Display program stack, including active

subprograms, names & values of

parameters and local variables. : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.Option to display only scalar parameters

and variables : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

YB_01TA

1.Display identification of each task : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Display type of each task : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Display scope or owner of each task : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.Identify current statement of each task : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5.Display status of each task : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2. Breakpoints

YB_02_A

1.Break on a subprogram (visible) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Break on a subprogram (not visible) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Break on a subprogram (ambiguous name) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.Break on an executable statement in

the current procedure : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5.Break on an executable statement in

a procedure not yet entered : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

6.Break in a declarative region : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

7.Break in an exception handler : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

8.Break on package body statement : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

9.Break when any exception is raised : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

10.Break when any subprogram is entered : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

11.Remove a breakpoint : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

12.Show all breakpoints : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

YB_02TA

1.Break when any rendezvous occurs : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Break when any task switch occurs : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Break when any task is aborted : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3. Single Stepping

YB_03_A

1.From one statement to the next : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Step to appropriate handler when statement

raises an exception : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Option to step through subprogram statements

when the current line contains a

subprogram call : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.When stepping through subprogram statements,

does stepping continue in an exception

handler when an exception is raised? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5.Option to break on return from a subprogram

when the current line contains a

subprogram call : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

6.When option to break on return is taken,

does stepping resume in an exception

handler if subprogram raises exception? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

7.Option to execute a specified number of

statements : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

YB_03TA

1.Step to next statement when next statement

is in a different task : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4. Examination of Variables

YB_04_A

1.In a library package (WITHed at current

location) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.In a library package (elaborated but not

WITHed at current location) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.In a library package (generic instantiation) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.Locally declared variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5.Variable with ambiguous simple name : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

6.Formal parameter : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

7.Predefined type integer variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

8.Predefined type float variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

9.Enumeration type variable :_

_________________

Command:_____________________________________________________________

_____________________________________________________________

10.Fixed point type variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

11.Array type variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

12.Record type with discriminants : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

13.Record type with unconstrained objects : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

14.Access type variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

15.Named number : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

16.Name of exception being handled : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

17.Attributes of variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

YB_04TA

1.Record type with task type components : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Task type variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Task attributes : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5. Interrupt Execution and Return Control to Debugger

YB_05_A : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

6. Watchpoints

YB_06_A

1.Static object in a library package : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Locally declared in main program : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Locally declared in subprogram (visible) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.Locally declared in subprogram (not visible) : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5.Variable declared within allocated object : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

6.Formal parameter : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

7.Variable modified by direct assignment : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

8.Actual parameter modified in a subprogram : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

9.Component of a record, modified by assignment

to record : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

10.Variable in an allocated object, modified by

one of several access variables : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

11.Formal parameter modified under an alias : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

12.Deallocated object : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

13.Collection : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

7. Traceback of Subprogram History

YB_07_A

1.Are names of subprograms correctly displayed? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Are statement numbers of calls given? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

YB_07TA

1.Are names of tasks and subprograms correctly

displayed? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Are statement numbers of calls given? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

8. Program History

YB_08_A

Command:_____________________________________________________________

_____________________________________________________________

9. Modification of Variables

YB_09_A

1.Modify a variable referenced by an access

type variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Modify a variable in a package : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Modify a local variable : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.Modify a constant : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5.Modify a names number : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

6.Ada constraints enforced : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

10. Control Flow Direction

YB_10_A

1.Restart a program from the beginning : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Restart a program in a different branch of

an IF statement : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

11. Integration with the Editor

YB_11_A

1.Enter the editor from the debugger and have

the editor cursor positioned in the same

place : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.From the debugger, modify source, recompile,

relink, and restart with the same set of

debugger commands : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

12. Applicability of the Debugger to Foreign Languages

YB_12_A

Break on return from an assembly language

subprogram : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

YB_12_B

Single step through inline machine code : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

13. Virtual Calendar

YB_13TA : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

14. Applicability of the Debugger to Interrupt Handlers

YB_14TA

1.Breakpoint in an Ada task tied to an

interrupt : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Resume execution after breakpoint : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

15. Conditional Breakpoints

YB_15_A

1.Break when one variable becomes greater than

another : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Break when a statement is executed for the

5th time : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

16. Macro Facility

YB_16_A

1.Display a set of variables with one command : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Display a set of variables when a breakpoint

is taken : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

17. Log File (Tracing)

YB_17_A : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

18. Isolation of Debugger I/O

YB_18_A : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

19. Access to Machine Properties

YB_19_A

1.Examine machine registers : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Stepping by machine instructions : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

20. Isolate Exception

YB_20_A

1.Break on any exception raised : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

Break on:

2. user-defined exception : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3. range constraint violation : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

4. storage error : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

5. program error : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

6.Did the break occur on the statement raising

the exception, or only in handler? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

YB_20TA

1.Break on tasking error : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Did the break occur on the statement raising

the exception, or only in handler? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

21. Non-terminating Tasks

YB_21TA

1.List all tasks created by a subprogram

and their status : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Display all tasks, master and status of

each task : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

22. Break on Failure in a Declarative Region

YB_22_A : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

23. Break on failure in library package body

initialization

YB_23_A : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

24. Library Package Elaboration Order

YB_24_A : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

25. Execution Time Degradation by Debugger

YB_25_A

0.CL_WH_WHET_01 performance test time : (Time)

1.With no breakpoints or watchpoints set : _ (Time)

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.With watchpoints set on several variables

whose values change frequently : _ (Time)

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.With breakpoints set on exceptions which

are not raised : _ (Time)

_________________

Command:_____________________________________________________________

_____________________________________________________________

4.With several breakpoints set but never

taken : _ (Time)

_________________

Command:_____________________________________________________________

_____________________________________________________________

26. Task Deadlock

YB_26TA

Does the debugger regain control when all

tasks deadlock, and allow examination of

the state of each task, including the

entry call on which it is waiting? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

27. Limits on the Number of Breakpoints

YB_27_A

1.Are 10 breakpoints allowed? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

2.Are 30 breakpoints allowed? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

3.Are 50 breakpoints allowed? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

28. Program Termination

YB_28_A

Is program termination treated as an implicit

breakpoint? : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

29. Debugger Command Files

YB_29_A : _

_________________

Command:_____________________________________________________________

_____________________________________________________________

=======================================================================

General comments:

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

Impressions:

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________