Date:	Thu, 25 Nov 1999 10:03:31 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Anton Helm <tony AT dictator DOT nt DOT tuwien DOT ac DOT at>
cc:	djgpp AT delorie DOT com
Subject:	Re: Problems with DJGPP lib and grx23
In-Reply-To:	<4.2.0.58.19991124161000.00a11cb0@hal.nt.tuwien.ac.at>
Message-ID:	<Pine.SUN.3.91.991125100314.11831G-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 24 Nov 1999, Anton Helm wrote:

>  >You (or someone) will have to dig a bit deeper: generate the crash
>  >inside a gdb session or write down the exact address found in the
>  >coredump (i.e. traceback). Then *disassemble* the above routine, and
>  >find out what instruction is causing the problems.  Print register
>  >contents. Try to deduce what's happening.
> 
> Main problem with debugging is that this is a graphic application
> and the problem is related to displaying a mouse cursor.
> I am no gdb guru either but to my experience it isn't that easy to
> debug such programs with gdb. (At least I always managed to avoid it.)

Did you try with the latest port of GDB 4.18?  If not, it changes the
situation: you can now debug any graphics program provided that the
video mode it uses is supported by the text output functions of the
BIOS interrupt 10h.  Of course, the debugger's output is mixed with
the graphics, and you need a screen redraw key in the application to
redraw the graphics after GDB's output scrolls some of it off the
screen, but these problems are not show-stoppers.

I actually used GDB to debug a complex graphics program, and it
worked reasonably well for me.  Since the case in point involves only
disassembly, I don't expect you'd have any problems at all with the
latest GDB binary.

- Raw text -