Message-Id:	<199809022352.TAA29052@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:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Date:	Thu, 3 Sep 1998 00:50:51 +0000
MIME-Version:	1.0
Subject:	Re: Allegro Aware Debugger
Reply-to:	mert0407 AT sable DOT ox DOT ac DOT uk
CC:	djgpp AT delorie DOT com

On  2 Sep 98 at 16:18, Salvador Eduardo Tropea (SET) wrote:

> > 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; 
> 
> If they use libdbg.a (almost sure) all will have the same limitations that 
> RHIDE and gdb have because they use the same routines.

Oh, I didn't know that RHIDE and GDB used libdbg.  FSDB and EDEBUG32 
certainly do, and yes, the limitations I mentioned are part of that 
library.

> > The other way to debug post-mortem is through a core dump.  
> 
> That's only usefull to analize a crash of the program in other machine, isn't 
> a good idea when you are hunting a bug, you'll need to move the "stop" a lot 
> of times, isn't much more easier just 1 run moving a breakpoint?

I think they're good for different things.  If you have a crash that 
you can't reproduce then a debugger is no help because you can't 
reproduce the problem.  A core dump would (hopefully) show what went 
wrong.  Personally I use the core dumps for most programs I write at 
the moment, and I have found them useful -- you can have a hunch what 
is wrong based upon just the call frame traceback given by symify, 
and the core dump can confirm this by showing the values of 
variables.

I know that a debugger can do this too, but you have to reproduce
the crash.  Perhaps it's mostly a matter of taste; as I mainly write
Allegro programs, and haven't had much success using debuggers on
them, I tend to avoid debuggers.  I don't seem to spend much time 
debugging anyway, so it doesn't matter much to me. :)

> I taked a quick look to your program as is very interesting to catch bugs 
> when the program crashed in other machine, for that is great, but not for 
> normal debugging.

Each to his own. :)  I'm not actually sure how useful it is for what
you suggest, because you have to get the core file to your debugging
machine, and they can be quite large.  In my system you can limit the
size, but this means that not everything will be saved.  The stack
gets priority, then the first DPMI memory block (which contains the
static code and data).  After that equal amounts (in 64k chunks) are
saved from the remaining DPMI memory blocks until the space quota
runs out.

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

- Raw text -