[an error occurred while processing this directive]
Node:Debug graphics,
Next:GDB and C++ source,
Previous:Crash dump,
Up:Debugging
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.