Mail Archives: djgpp/1998/09/02/15:17:13
"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
- Raw text -