Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD17 - Debugging  

  LSE17 - Debuggen

Contents  
  • 1 Allocation to V-Model and Methods Allocation
  • 2 Brief Characteristics
  • 3 Requirements
  •       3.1 Requirements for Interfaces
  •       3.2 Requirements for the Methods Support
  •       3.3 Requirements for Functions
  •       3.4 Other Requirements
  • 1 Allocation to V-Model and Methods Allocation

    V-Model

    SD6.3 - Self-Assesment of the SW Module/Database

  • Technical Requirements.Technical Requirements for the Development
    and SWMM Environment
  • SW Modules
  • Technical Requirements.Technical Requirements for the Development
    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

    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.

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster