Debugger Architecture

IBM Rational® DOORS® does not offer native debugging capability.
In order to support debugging, the DXL Editor needs to instrument the DXL file the user requests to execute.

Here are the debugger steps:

Parse the DXL source file
The parser will analyze the DXL code to locate source artifacts that are relevant to the debugger: function declarations, variable declarations, loops, etc.
Augment the DXL code with debugging instructions
The debugger will insert DXL statements in the located source artifacts to be notified when the execution enters a function or when a variable is defined for example. The augmented code is saved in a temporary file, so that the source DXL file is left untouched. The DXL Debugger executes this augmented code rather than the original DXL file.
Resolve include statements
The parser will analyze the include statements. It will resolve includes paths to absolute file locations in the file system. Then the parser will recursively augment the included files, so that the user can step into functions defined in these locations.
Note that the user may request to ignore include statements, and thus to be able to debug only the main DXL file.
Communicate with IDE
A communication layer enables the debugged DXL file to notify the IDE about executed functions, and enables the IDE to request to suspend the execution.

Notes

If present in the DXL source file, the instruction "pragram runLim" is stripped from the augmented code. This is to prevent DOORS from opening a dialog box about execution timeout while you are stepping into functions and inspecting variables.
Being able to suspend at any time the execution and being able to see variable values requires some extra work to be done by the debugger, compared to a regular execution (Run mode). This may lead a small performance penalty, that we hope to be acceptable in comparison to the benefit of having debugging capability.

Related concepts
Debugger