Message-Id: <m0zEINw-000S8SC@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,
        rylan AT intekom DOT co DOT za
Date: Wed, 2 Sep 1998 16:18:10 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Allegro Aware Debugger
In-reply-to: <199809021752.NAA29961@delorie.com>
Precedence: bulk

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

Just to clarify some things:

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

If they use libdbg.a (almost sure) all will have the same limitations that 
RHIDE and gdb have because they use the same routines.

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

RHIDE supports it without any extra stuff, just plug the second monitor to 
the computer.
 
> 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. 

Normally imposible if you are handling a lot of data. Or too hard if the 
program involves too much operations.

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

And you need to write tons of lines to log it, your source code becomes huge 
and messy, I preffer a debugger.
 
> 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?

> 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

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.

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