Problems with debugging

Debugging macros is a little more tricky than normal code because a macro may consist of any number of single lines of code. Stepping single lines of code will result in the debugger simply sitting on a line of languageONE code until each single line in the macro has been completed. In order to circumvent this problem, languageONE, when reWritten in debugging mode, will insert a line of code at the beginning of each macro that sets a byte named "STOP" to zero. A macro is then inserted prior to each languageONE component macro that sets the same byte ("STOP") to 1. A debugger trap may then be set to stop when the byte becomes 1.

GDB is the formost debugger used on Linux systems and there are a number of "front ends" that transform using GDB into a "graphic" experience. DDD is very useful front-end although it has not been maintained for a number of years. INSIGHT is another front-end, although I believe it has a version of GDB inbuilt and so varies a little from the most recent versions of GDB. If you can get good use from either of these two debugger front-ends then they will suit your needs, however my experience has been that XXGDB is of most use for debugging a languageONE program. It is the simplest debugger, without a great deal of functionality but has proved to be the most solid of the 3 listed here.


There is a great deal of information freely available for GDB, and by extension XXGDB, therefore I will only present details here that represent a starting point in the debugging of a languageONE program.


is a file that may be created in the working directory (where xxgdb is started) that will define the characteristics of a newly started gdb session. It is here that controlling the languageONE debugging session can be made easier. By coding an initial label (or any number of labels) in your program and then setting breakpoints, program flow may be controlled. Breakpoints may be "enabled" and "disabled" at your desire.

In order to step thru a languageONE program you will need to set a "watchpoint", essentially a breakpoint that is triggered whenever a particular value is detected. As previously stated, a langaugeONE program - reWritten with debugging mode - will have created a byte named "STOP" and by watching this byte the debugger will break when a proposed value is detected. The directive "watch STOP if STOP==1" will break at each line of a languageONE program and allow for stepping thru line by line. In turn this watchpoint may be "enabled" and "disabled" as desired.

In addition, reWriting a languageONE program with the debug set will direct the reWriter to insert a label at each line of code. These can be used as arguments to the runto command shown below

The following lines of code within .gdbinit will automate the debugging process

  • break _progstart
  • watch STOP if STOP==1
  • disable 2
  • define runto
    • disable 2
    • break $arg0
    • cont
    • disable 3
    • enable 2
  • end

"runto" is a user defined command which will allow a program to progress to a defined label without stoping at every line. it simply disables break 2, sets a break at the requested label, continues to that label and then re-enables break 2. Unfortuneately I have not been able to align the source with the new position within a GDB command so directly after using the command, it is necessary to issue the "list" command to relist the source in the correct place.

Admittedly, debugging a languageONE program requires more thought than other comparable systems, but by combining "breakpoints" and the STOP "watchpoint", in addition to the inbuilt function of displaying subroutine entry and exit points, a result may be achieved. It is probably best to make use of these methods in order to locate the area of a program where a bug may reside prior to commencing a more detailed inspection of the program.

Note:That it is the "raw" version of the program - the one that has been produced by the "reWrite" function - that is displayed by XXGDB

XXGDB can be configured via the .XDefaults file in your home directory. I have used the following entrees to locate the 4 windows and to provide background colours

  • *quit.background: red
  • *run.background: green
  • *cont.background: green
  • XDbx.geometry: +1050+675
  • *dialogWindow.background: snow3
  • *sourceShell.geometry: 550x600+1050+50
  • *sourceWindow.background: snow3
  • *commandShell.geometry: 190x400+1610+50
  • *commandWindow.background: cyan
  • *displayShell.geometry: 300x300+1610+475
  • *displayWindow.background: snow3