From:	"Barry" <barryem AT yahoo DOT com>
Newsgroups:	comp.os.msdos.djgpp
References:	<dkWU4.233569$AT6 DOT 336820 AT dfw-read DOT news DOT verio DOT net> <200005191228 DOT IAA23653 AT indy DOT delorie DOT com>
Subject:	Re: Debugging graphics
Lines:	80
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 5.00.2919.6600
X-MIMEOLE:	Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:	<5ydV4.238061$AT6.341123@dfw-read.news.verio.net>
Date:	Fri, 19 May 2000 10:59:40 -0500
NNTP-Posting-Host:	204.2.12.131
X-Complaints-To:	abuse AT verio DOT net
X-Trace:	dfw-read.news.verio.net 958752001 204.2.12.131 (Fri, 19 May 2000 16:00:01 GMT)
NNTP-Posting-Date:	Fri, 19 May 2000 16:00:01 GMT
Organization:	Verio
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Eli Zaretskii" <eliz AT delorie DOT com> wrote in message
>
> 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.

I'm using gdb 4.18b.

> Make sure you have the latest version of RHIDE.

I do.

> > 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.

Good thought.  I'll try that.

> > 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?

The program crashes before main.  I've tried setting a breakpoint
at main and then using the RUN command and it crashes.  Before this
problem started that would take it to main and stop at the
breakpoint.

I have 2 of these computers both set up exactly the same.  In fact
one setup was copied directy to the other one.  I took this same
source file and moved it to the other computer and it works just
fine in rhide and rhgdb.  But it still won't work on the computer I
was using.  I've replaced rhide and rhgdb on that computer with the
one from the other computer but it doesnt help.

I think Im going to recopy my setup.  It should be ok then.  But
I'm not sure what I did to cause this and I don't know how to keep
it from happening again.  Maybe I'll get lucky and it won't.

Thanks for your help.

Barry

- Raw text -