 |
 |
 |
|
 |
|||
| SSD17 - Debugging |
LSE17 - Debuggen
1 Allocation to V-Model and Methods Allocation
V-Model
SD6.3 - Self-Assesment of the SW Module/Database
and SWMM Environment
SW Modules
and SWMM Environment
SW Modules
Method
none
2 Brief Characteristics
This service unit defines the requirements for tools applied to reproduce errors and to locate the errors in the source code.In this connection, it is intended
- to investigate internal states of a load module at source code level (e. g. variable assignment, call structure),
- to walk through load modules at source code or machine code level, i. e. instruction by instruction, and
- to stop load modules at previously defined break and watch points; manipulations can then be realized (e. g. for variables).
3 Requirements
3.1 Requirements for Interfaces
| SSD17.I.1 | Granularity |
The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface.
|
SSD17.I.2 |
Input interface to SSD12 - Generating Components and Modules
|
It is possible to integrate source code generated with SSD12 for Components and Modules without further transformation from the object management for debugging purposes.
|
SSD17.I.3 |
Input interface to SSD16 - Linking
|
It is possible to integrate code linked with SSD16 without further transformation from the object management for debugging purposes.
|
SSD17.I.4 |
Technical dividing
|
In case development and target systems are not identical the tool consists of two parts; one part runs on the development system (referred to as "development computer-dependent part"), the other part runs on the target system (referred to as "target computer-dependent part").
|
SSD17.I.5 |
Communication
|
The development computer-dependent part and the target computer-dependent part communicate with each other. | Standard coupling ways are a serial connection (RS232 interface) or an Ethernet connection.
SSD17.I.6 |
Constant system behavior
|
The system behavior is not changed by modifications of the load module. | By modifying the code of the load module for debugging purposes, the behavior may change so errors can be no longer reproduced. Code modifications of the load module may also result in another time behavior. |
3.2 Requirements for the Methods Support
none
3.3 Requirements for Functions
| SSD17.F.1 |
Debugging on source code level
|
SSD17.F.1.1 |
Break Points
|
SSD17.F.1.1.1 |
Statements
|
It is possible to set and to delete break points in connection with the conventional statement types like Assignment Statement, Do Statement, Go To Statement, and Sub-Program Call. | A "break point" identifies a statement or an expression in the source code. The break point is activated when the statement or the expression is executed. In the case of a deactivated break point there is no interruption.
SSD17.F.1.1.2 |
Instantiations
|
It is possible to set and to delete break points within generic instantiations.
|
SSD17.F.1.1.3 |
Inline procedures
|
It is possible to set and to delete break points within inline procedures.
|
SSD17.F.1.1.4 |
Conditional entry call
|
It is possible to set and to delete break points at conditional entry calls.
|
SSD17.F.1.1.5 |
Accept statements
|
It is possible to set and to delete break points in accept statements.
|
SSD17.F.1.1.6 |
Exception handler
|
It is possible to set and to delete break points in exception handlers.
|
SSD17.F.1.1.7 |
Time delay
|
Set break points are automatically activated after a selectable time. | Each additional break point requires further processor performance to control this break point.
SSD17.F.1.1.8 |
Looping-dependent activation
|
Set break points are automatically activated if the number of executions of a statement has reached a selectable number.
|
SSD17.F.1.2 |
Watch points
|
It is possible to set and to delete watch points. | A "watch point" identifies an operand. The watch point is activated after the variable is addressed. In the case of a deactivated watch point there is no interruption.
SSD17.F.1.3 |
Single step execution
|
SSD17.F.1.3.1 |
Call
|
Single step execution on the level of subprogram call is possible.
|
SSD17.F.1.3.2 |
Subprogram entry/exit
|
Single step execution on the level of subprogram entry and subprogram exit is possible.
|
SSD17.F.1.3.3 |
Parameter transmission
|
Single step execution on the level of parameter transmission is possible.
|
SSD17.F.1.3.4 |
Branching/assignment
|
Single step execution on the level of branching and allocation is possible.
|
SSD17.F.1.3.5 |
Optional number
|
It is possible to execute a selectable number of lines and statements.
|
SSD17.F.1.3.6 |
Display
|
When executing single steps the executed statements are displayed.
|
SSD17.F.1.4 |
Support of language characteristics
|
SSD17.F.1.4.1 |
Manipulation of symbolic variables
|
It is possible to read and write symbolic variables of the source program.
|
SSD17.F.1.4.2 |
Interpreting
|
Source code expressions are interpreted.
|
SSD17.F.1.4.3 |
Manipulation of files
|
It is possible to modify the content of opened files on source code level.
|
SSD17.F.1.5 |
Logging
|
SSD17.F.1.5.1 |
On/off
|
It is possible to activate and to deactivate the logging for debugging sessions. | Input to and output from the tool are logged so it will be possible to reconstruct the debugging session at some later time.
SSD17.F.1.5.2 |
Program output
|
It is possible to log the output of the load module.
|
SSD17.F.1.6 |
Status output
|
A complete output of the current tool status is possible. | This includes a list of all break and watch points, the display of the call hierarchy of the subprograms, the current position in the program, status information about processes (if relevant) and information about the memory allocation.
SSD17.F.2 |
Debugging on machine code level
|
SSD17.F.2.1 |
Machine Code Debugger
|
The basic functionality of a machine code debugger is available. | The basic functionality comprises break and watch points as well as program execution and control on instruction level and display of the program run.
SSD17.F.2.2 |
Display and output
|
SSD17.F.2.2.1 |
Break and watch points
|
It is possible to display break and watch points together with the instructions.
|
SSD17.F.2.2.2 |
Memory contents
|
SSD17.F.2.2.2.1 |
Dump
|
It is possible to dump memory and register contents.
|
SSD17.F.2.2.2.2 |
Modification
|
It is possible to modify the content of memory areas.
|
SSD17.F.2.3 |
Manipulation of object code
|
SSD17.F.2.3.1 |
Assembler code
|
When debugging machine code, assembler code is used to replace, to modify or to enlarge parts of the object code in the memory. | This kind of manipulation of object code is frequently referred to as "patch".
SSD17.F.2.3.2 |
Machine-oriented addressing
|
The access mechanism of the tool allows-beyond symbolic variables-the addressing of each memory cell of the program in the smallest possible unit of the corresponding machine architecture. | In byte-oriented machine architectures this unit is the byte.
SSD17.F.2.3.3 |
Locking manipulated objects
|
After ending a debugging session, all objects for which instructions were manipulated are locked for following non-privileged accesses. | This way it is guaranteed that the displayed source text matches the source text used to execute the load module.
SSD17.F.2.3.4 |
Message
|
Prior to the first manipulation of object code a message is displayed which states that this object will be locked for following non-privileged accesses after ending the debugging session.
|
SSD17.F.3 |
Structuring of a debugging session
|
SSD17.F.3.1 |
Stop
|
SSD17.F.3.1.1 |
Prior to condition
|
It is possible to pause the program run in the source program prior to a met condition.
|
SSD17.F.3.1.2 |
After condition
|
It is possible to pause the program run in the source program after a met condition.
|
SSD17.F.3.2 |
Skipping
|
It is possible to skip parts of a program during the program execution. | The next source line or source statement after the skipped program part will be executed.
SSD17.F.3.3 |
Command files
|
Debugger command files are executable during a session. | Thus it is possible to execute a number of commands automatically without having to enter them manually during each new program run.
SSD17.F.3.4 |
Automatic
|
It is possible to get a logged debugging session (see SSD17.F.1.5.1) automatically re-executed right from the beginning.
|
SSD17.F.3.5 |
File input/output
|
It is possible to reroute input and output of the load module to other files, if required. | When reading from a hardware-oriented device (e. g. analog-to-digital converter) this kind of rerouting to a file as input source is not advisable.
SSD17.F.3.6 |
Work status
|
It is possible to interrupt a debugging session and to continue with the previous work status.
|
SSD17.F.3.7 |
Restart
|
It is possible to start a load module without loading it again, i. e. in case the object module has not been manipulated. | This way it is possible to save time.
SSD17.F.3.8 |
Automatic
|
At a break or watch point, it is possible to activate the automatic execution of a debugger command sequence with all kinds of debugger commands.
|
SSD17.F.3.9 |
Process behavior
|
It is possible to define if-during an interruption because of a break or watch point-all processes pause or if only the interrupted program part pauses and all other processes continue to run normally. | The second version makes sense if input data have to be processed during certain time intervals in real-time mode.
SSD17.F.4 |
Normal execution
|
It is possible to execute a program compiled for debugging without debugging as well.
|
SSD17.F.5 |
Ada-specific requirements
|
SSD17.F.5.1 |
Ada processes
|
SSD17.F.5.1.1 |
Priorities
|
It is possible to change the priorities of Ada processes while being executed.
|
SSD17.F.5.1.2 |
Start/end
|
It is possible to start and to end Ada processes.
|
SSD17.F.5.2 |
Ada exceptions
|
SSD17.F.5.2.1 |
Explicit initiation
|
It is possible to raise Ada exceptions explicitly.
|
SSD17.F.5.2.2 |
Exceptions without consequences
|
It is possible to ignore Ada exceptions.
|
SSD17.F.5.3 |
Ada semantics
|
SSD17.F.5.3.1 |
Navigation in processes/subprograms
|
SSD17.F.5.3.1.1 |
Processes
|
It is possible to navigate in the set of active and inactive Ada processes.
|
SSD17.F.5.3.1.2 |
Subprograms
|
It is possible to navigate appropriately in the set of called and yet uncompleted subprograms. | It is possible to navigate to the static or even dynamic predecessor of a subprogram
SSD17.F.5.3.1.3 |
Packages
|
It is possible to navigate in the set of surrounding packages.
|
SSD17.F.5.3.2 |
Navigation in the name area
|
SSD17.F.5.3.2.1 |
Identification
|
When navigating, it is possible to identify the corresponding program units.
|
SSD17.F.5.3.2.2 |
Read and write
|
When navigating, it is possible to read and to write the variables contained in the name area.
|
SSD17.F.5.3.3 |
Requests
|
SSD17.F.5.3.3.1 |
Internal source construct
|
It is possible to get information about the current internal source construct on request.
|
SSD17.F.5.3.3.2 |
Compilation unit
|
It is possible to get information about the current Ada compilation unit on request.
|
SSD17.F.5.3.3.3 |
Long name
|
It is possible to get information about the full name of the innermost named and current Ada construct on request.
|
SSD17.F.5.3.4 |
Visibility rules
|
The visibility rules of program language Ada are taken into consideration.
|
SSD17.F.5.3.5 |
Overloaded variable
|
It is possible to access overloaded Ada variables via context information.
|
SSD17.F.5.3.6 |
Elaboration code
|
It is possible to control the elaboration of declarations. | After the elaboration of a declaration, the declaration is valid. After the elaboration of a variable declaration, the variable is generated with the declared type so it can be addressed.
SSD17.F.6 |
Consistency check
|
SSD17.F.6.1 |
Disassembling
|
It is possible to transform executable code backwards into assembly language.
|
SSD17.F.6.2 |
Inconsistencies
|
It is possible to investiga6te the (assembled) source code and the disassembled executable code with regard to inconsistencies.
| | |||||||||||||||||||
3.4 Other Requirements
| SSD17.O.1 | Upward compatibility |
It must be possible to process objects generated with an older release of the tool with the later release of that tool, without loss of information and functionality.
|
SSD17.O.2 |
Procedural command language
|
The tool has a procedural command language that can be applied by the user to generate and run macros or procedures.
|
SSD17.O.3 |
Complexity
|
There is no limitation of the complexity caused by the tool itself.
|
|
|
|
|
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
|