Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: "George Foot" , djgpp AT delorie DOT com Date: Thu, 3 Sep 1998 14:25:16 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Allegro Aware Debugger In-reply-to: <199809022352.TAA29052@delorie.com> Precedence: bulk "George Foot" 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