From: kagel AT quasar DOT bloomberg DOT com
Date: Wed, 13 Nov 1996 10:33:03 -0500
Message-Id: <9611131533.AA04113@quasar.bloomberg.com >
To: beable AT magna DOT com DOT au
Cc: djgpp AT delorie DOT com
In-Reply-To: <3289C871.58DE@magna.com.au> (beable@magna.com.au)
Subject: Re: Post mortem debugging and the like...Help...
Reply-To: kagel AT dg1 DOT bloomberg DOT com

   Errors-To: postmaster AT bloomberg DOT com
   Date: Wed, 13 Nov 1996 23:09:05 +1000
   From: "Martin....." <beable AT magna DOT com DOT au>
   X-Mailer: Mozilla 3.0Gold (Win95; I)
   Mime-Version: 1.0
   Content-Transfer-Encoding: 7bit
   Content-Type: text/plain; charset=us-ascii
   Content-Length: 975

   G'day,

	   I am in the middle of writing a couple of test programs using DJGPP(a
   dam fine compiler I might add) and was wondering if there was any way of
   having a post portem debugging environment. I'm talking about something
   like what the old modula-2 compilers used to have, where if an
   unexpected crash occured, the compiled program would write out a dump
   file which could later be analized with a debug version of the code.

	   I was reading thru the notes that came with Quake, (since id used DJGPP
   to write it I was looking for clues). I found mention of the that the
   bug reports required the eight-digit number which comes after the eip=.
   I take it that this comes from Charles Sandman's DPMI.

	   Of what value is the 'eip=' number and is this a pointer or clue as to
   what could have gone wrong in the program?? Is there any other method of
   debugging a DJGPP executable after the fact??

For now we do have 'symify' which, when run after a crash, will translate the
symbolic addresses left on the screen after the crash into a stack trace.
Check out the faq and info page for symify.

-- 
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com

A proverb is no proverb to you 'till life has illustrated it.  -- John Keats