Message-Id: <199809021752.NAA29961@delorie.com>
Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: "George Foot" <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: Rylan <rylan AT intekom DOT co DOT za>
Date: Wed, 2 Sep 1998 18:50:29 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Allegro Aware Debugger
Reply-to: mert0407 AT sable DOT ox DOT ac DOT uk
CC: djgpp AT delorie DOT com
Precedence: bulk

On  1 Sep 98 at 14:00, Rylan wrote:

> Has anybody got any idea when an Allegro aware debugger might come available
> for DJGPP? Cause as everyone know, GDB and /or RHGDB crashes when you try to
> debug SVGA using Allegro code - any ideas? How can I debug SVGA and  / or
> truecolor Allegro programs? Right know I am on a clumsy system of writing
> reams of debug code, which in itself sometimes have errors, so I desperately
> need an Allegro aware debbugger.

I think there will be more problems than just determining the 
graphics mode.  Most Allegro programs hook a variety of hardware 
interrupts, and the FSDB and EDEBUG32 debuggers can't allow this; I'm 
not sure about GDB.  Also consider that most Allegro programs are 
fairly real-time -- they might not like being interrupted by the 
debugger.

However, FSDB does support dual screen debugging, so if you have a 
second (monochrome) monitor connected it can display its own output 
there, leaving your main monitor free for use by the Allegro program. 
This is also possible with GDB using a separate program -- see the 
FAQ section 12.5 for many details on debugging graphics programs.

Personally I don't much like the concept of debugging a program
while it's still running.  The alternative is to do the debugging
post-mortem, i.e. after your program has died.  There are two main
ways to do this; one way is to dump reams of diagnostic information
to a file while the program runs, and sift through it later on.  I
tend to do this quite a lot (with options to disable the output of
course!).  This is the only way of getting confirmation about which
functions were executed in what order, with what parameters, etc.

The other way to debug post-mortem is through a core dump.  If you 
set up a signal handler which dumps your program's entire memory 
image (or as much of it as is feasible) then you can look through 
this later -- not by hand of course!  A while ago I wrote a simple 
core dump system and post mortem debugger for djgpp; the debugger is 
very primitive but functional and is easy to adapt from sources if 
you need to.  The most powerful feature of this system is the ability 
to browse through your program's memory space, identifying NULL or 
invalid pointers for instance.  I started looking into making GDB 
able to read these core dumps, but I got sidetracked.

If you want to download this post mortem debugger then there's a 
version here:

    http://users.ox.ac.uk/~mert0407/download/pmdb04s.zip

Please read the readmes.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk