Mail Archives: djgpp/1995/12/05/07:56:41
On Mon, 4 Dec 1995, James Tsillas wrote:
> I couldn't find anything in the FAQ and I'm at a loss as to where any
> documentation on gdb is so here goes:
>
> I'm developing DOS graphics applications and am utilizing all of
> graphics memory to store the displayed image. This makes debugging
> impossible using the standard display.
You probably didn't read the latest version of the FAQ (it's available as
faq102.zip from the same place you get DJGPP). It discusses this problem
and the possible solutions in section 12.7:
12.7 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: Redirect the debugger output to another (monochrome) monitor by
putting ``mono'' into your GO32 environment variable, like this:
set GO32=mono
(Note: GDB doesn't support such a redirection yet, but other
debuggers do.)
Alternatively, you can redirect the debugger output to your
printer, like this:
go32 -d gdb myprog > prn
You might also consider using the LadyBUG debugger which supports
remote debugging over a serial link (but it's not source-level).
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 <dj AT delorie DOT com> and is
available by anonymous ftp to omnigate.clarkson.edu, directory
pub/msdos/djgpp/pub, file mshell.zip, and also as mshell10.zip
at ftp.delorie.com:/pub/djgpp/ofc/.
> Also, is there a source level debugger which is better than gdb? One
> that can do full screen debugging with source.
No. You can try FSDB or LadyBug which *are* full-screen (ala Turbo
Debugger), but they are *not* source-level, although they will show source
code together with the disassembled program.
- Raw text -