Node:Debug graphics, Next:, Previous:Crash dump, Up:Debugging

12.3 How to debug a graphics program

Q: How can I debug a graphics program? The debugger runs my program fine, but when a breakpoint is hit with the screen in a graphics mode I can't read the text printed by the debugger.

A: You can redirect the debugger output to your printer, like this:

 gdb myprog > prn

This will only work if the program itself doesn't write to stdout (graphics programs usually don't); otherwise the debugger output will get mixed up with your program's output. If you use GDB 4.18 or later, you can work around this by redirecting the standard output of the debugged program to a different file or device as part of the run command, like this:

 run > foo.out

Beginning with version 4.18, the ported GDB writes its output to the screen in a way that works even in graphics modes, provided that the system BIOS knows about the specific graphics mode your program uses.

RHIDE and RHGDB support debugging graphics programs by switching between debugger's and program's screen, so you can use RHIDE's built-in debugger or the stand-alone RHGDB subset. This support doesn't work for all video modes, but the standard VGA modes and VESA modes are supported. If you debug with RHIDE on Windows, switch your RHIDE session to full-screen before starting the debug session, otherwise Windows will cause problems when RHIDE switches between the program's graphics screen and RHIDE's own text screen.

The FSDB debugger can switch between the application screen and the debugger screen, so you might use it, at a price of working with a low-level debugger. Press Alt-<F5> to switch between the two screens. Stock FSDB as distributed with DJGPP can only do this with text screens, but a modified version of FSDB with graphics support is available that knows about many graphics modes. The same distribution can also be found on the Oulu repository.

As yet another possibility, consider using the MSHELL program which will redirect I/O from any program to the monochrome monitor at the BIOS level, so you can use it even with GDB. MSHELL was written by DJ Delorie and is available from DJ's server. Be sure that you don't have some other TSR installed that catches screen writes and bypasses the BIOS functions, or else MSHELL won't help you. For example, changing the code page (with the DOS CHCP or MODE commands) might do this.

RHIDE also supports dual-monitor systems for debugging, it allows you to use the monochrome monitor for interface with the debugger, while leaving the color screen for your program's display, with no need to swap between them.

If you have any problems with dual-monitor support, in particular with RHIDE, make sure your memory manager doesn't grab the B000 segment for its own purposes. This region should be available for the mono adapter, or your system might crash when you try using it.

Another way to redirect the output of a program to a monochrome monitor is by using the MDA display driver from BinaryInfosys. It is a true DOS device driver, and so can be opened as a file--handy for sending debug info, for example. This driver is free and is available from BinaryInfosys' home page.