Date:	Fri, 19 May 2000 08:28:53 -0400 (EDT)
Message-Id:	<200005191228.IAA23653@indy.delorie.com>
From:	Eli Zaretskii <eliz AT delorie DOT com>
To:	"Barry" <barryem AT yahoo DOT com>
CC:	djgpp AT delorie DOT com
In-reply-to:	<dkWU4.233569$AT6.336820@dfw-read.news.verio.net>
	(barryem AT yahoo DOT com)
Subject:	Re: Debugging graphics
References:	<dkWU4.233569$AT6 DOT 336820 AT dfw-read DOT news DOT verio DOT net>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: "Barry" <barryem AT yahoo DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Thu, 18 May 2000 13:05:26 -0500
> 
> I've recompiled but that doesn't change anything.  The program runs
> ok without the debugger.  I've also tried using gdb and it works
> fine in gdb but I can't see anything once it goes into graphics
> mode since I can't figure out how to get gdb to do screen swapping
> if it will do it.

GDB 4.18 supports only those graphics mode which your system BIOS
supports.  That means video modes 0-13h.  If your program uses an SVGA
mode not supported by the system BIOS, GDB will not support it.
(Versions of GDB before 4.18 didn't even support standard BIOS modes.)

Even if you do use one of the standard modes, debugging such a program
in GDB is awkward: the graphics display scrolls off the screen as you
type commands and get responses from GDB.

For full-fledged debugging of graphics programs, you need to use
RHIDE.  It has code to switch between user and debugger's screen; that
code might give you trouble on Windows or with some buggy SVGA cards,
though.

For more info, look at section 12.3 of the DJGPP FAQ.

> I then tried using rhide and I compiled it in the IDE and as soon
> as I try to run or step or anything, I get a math error and the
> program stops.

Make sure you have the latest version of RHIDE.

> Does anyone know a way I can get gdb to swap back into text mode to
> give me listings when the program being debugged is in graphics
> mode? (since I'm using xmode I'm not real hopeful here).

One way to do this is to include in your program a function that
toggles between text and graphics mode, and then call that function
from GDB, when the program stops at a breakpoint.  (GDB has a `call'
command which can call arbitrary function in the debugged program.)
For this to work, that function should redraw the screen once it
switches to graphics.

> Does anyone know how I can use these tools to follow the program in
> assembly before it gets to main to try to get some clue about
> what's happening?

Put a breakpoint in a function called `__crt1_startup' or in `start',
and use the `stepi' and `nexti' commands to step through the startup
code on the assembly level.

But why would you need to step through the startup code?

- Raw text -