Message-Id:	<m0zEd6B-000S53C@inti.gov.ar>
Comments:	Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization:	INTI
To:	"George Foot" <george DOT foot AT merton DOT oxford DOT ac DOT uk>, djgpp AT delorie DOT com
Date:	Thu, 3 Sep 1998 14:25:16 +0000
MIME-Version:	1.0
Subject:	Re: Allegro Aware Debugger
In-reply-to:	<199809022352.TAA29052@delorie.com>

"George Foot" <george DOT foot AT merton DOT oxford DOT ac DOT uk> wrote:

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

That's why I think that's good to analize crashes in the machines of the 
users.

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

I know the core can be very large but is the only way to analize a crash when 
the user doesn't really know what sequence of operations produced the crash.

SET 
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013

- Raw text -