This section introduces some terms and principles to help you better understand the debugger.
In XD, a source line is considered executable if there are CPU instructions corresponding to it. Breakpoints may be placed only on executable lines, only executable lines are displayed in the Mixed mode, etc. Obviously, source lines containing comments or declarations are not executable. However, native code XDS compilers may generate no code even for lines containing statements, because of optimization or, for instance, if that code would be unreachable anyway:
PROCEDURE P(i : CARDINAL): CARDINAL; BEGIN CASE i OF |0: RETURN 1 |1: RETURN P(i-1) END; RETURN 2 (* Warning: Unreachable code *) END P;
In the above example, passing any value other than 0 or 1 as an input parameter to P would cause the language exception caseSelectException to be raised. Hence, the code corresponding to the last RETURN statement would never be executed and is omitted in the resulting object file. The "Unreachable code" warning is issued during compilation.
In addition to the code correspondent to a procedure's body, a compiler usually inserts some initialization (so called prologue) after its entry point and some cleanup (epilogue) before the RET instruction. In particular, the XDS compiler may generate code which saves and restores stack frame, installs and removes exception handlers, etc.
The compiler maps a prologue to the source line containing the procedure's BEGIN, and an epilogue to the line containing END.
Even if you turn the NOOPTIMIZE option on, the compiler still performs some optimizations. In particular, it may place local variables onto CPU registers. The debugger prepends names of register variables with an exclamation mark in information windows. Such variables may not exist at certain points of procedure execution, so the displayed values may be incorrect and it is not possible to modify a register variable.
When register variables are used in expressions, they are treated as unsigned integers.
In a C program, the main() function has the public name main or _main. To ensure compatibility with third-party debuggers and other tools, XDS compilers assign one of these names to the main module body entry point, depending on the CC option setting. After the program is loaded, XD searches its symbol table for these symbols and automatically executes the program's startup code up to the point the located symbol refers to. If you wish to debug the startup code, use the Restart at startup command or specify the /S option in XD command line.
If the program does not have a symbol table or there is no main or _main symbol in the code segment, the program will be stopped at the first possible point, as if the Restart at startup command was used.
Before invoking the debugger, ensure that your program is built with line number and symbolic debug information. To do this, switch the LINENO and GENDEBUG options on in the project file or on the command line. You may also wish to switch on the NOOPTIMIZE option in order to disable the machine-independent optimizer. Use the =ALL submode to force all modules which constitute your program to be recompiled with these option settings.
Do not forget to specify a linker option (/DEBUG for XDS Linker) which would cause debugging information to be bound to the executable. If you are taking advantage of the XDS make facility, it will be done automatically if you specify the GENDEBUG compiler option, provided that you use a template file bundled with your XDS package. Refer to an appropriate documentation if you use a third-party linker which is not supported in standard template files.
The Native XDS-x86 compiler is capable to produce debug information in two formats: CodeView (default under Windows NT/95) and HLL4 (default under OS/2). This is controlled by the DBGFMT compiler option. The HLL4 format is more suitable for Modula-2/Oberon-2 programs. For instance, it allows to represent sets and enumerations, which are not supported in CodeView. XDS Linker and XDS Debugger accept both formats on both platforms, so use HLL4 whenever possible.
HLL4 support under Windows NT/95 is probably an unique feature, so if you use any third-party tools, CodeView is your only option. Under OS/2, you have to use CodeView if you want to debug your program with Watcom debugger WD or IBM's IPMD debugger bundled with IBM CSet++. The new ICSDEBUG included into IBM VisualAge C++ product accepts HLL4.
To invoke XD from the command line, type
xd [<options>] [<executable> [<arguments>]]
xd /b [<options>] <control file>
and press Enter. Available options are:
|/D||Invoke XD in dialog mode (default)|
|/B||Invoke XD in batch mode|
|/H||Print a brief help message|
|/L||Create log file|
|/N||Display file names without path|
|/S||Debug startup code|
|/Xnnn||Set width of XD session window to nnn|
|/Ynnn||Set height of XD session window to nnn|
If you invoke XD without any parameters, it will start in dialog mode and display the Load Program dialog.
To exit the dialog mode, select Exit from the File menu or press Alt-X. If the debugger was started in the dialog mode, it will terminate. Otherwise (the dialog mode was activated from a control file), control file proceccing will continue.
To interrupt XD running in the batch mode, press Ctrl+C.