Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga
Subject: Re: Lattice Debugger
Keywords: Source Level Debugger
Message-ID: <595@sas.UUCP>
Date: 9 Aug 88 22:18:44 GMT
References: <61642@sun.uucp> <340@richp1.UUCP> <586@sas.UUCP> <1483@ucqais.uc.edu>
Reply-To: walker@sas.UUCP (Doug Walker)
Organization: SAS Institute Inc, Cary NC
Lines: 27

In article <1483@ucqais.uc.edu> blubaugh@ucqais.uc.edu (Dwight Blubaugh) writes:
>  I didn't get a chance to ask Lattice about how their debugger will
>work with the IFF pgtb stuff they presented at DEVCON. Both a source
>level debugger and trace back capability could prove interesting.
>I hope that Lattice get the debugger out by fall because I will switch back
>to lattice C when they do.

A couple of points:
1. Although I work for SAS, and SAS owns Lattice, I have nothing to do with
   C compiler development, so these comments are all my impressions from 
   seeing the stuff, alpha testing it, and informal conversations with
   John Toebes.

2. The IFF PGTB stuff was not presented by Lattice, it was presented by
   the Software Distillery (of which both John and I are members.)  The
   Distillery is working on support for the PGTB in the form of a TB program
   to let you get a traceback, etc.  The form is intended to be entirely
   non-partisan, not a Lattice-only thing.  That way any tools that come
   out to deal with PGTB forms will work on anybody's PGTB forms.

3. One feature that has been discussed for the debugger, although I'm not
   sure if it actually got into the first version, is the ability to load
   a PGTB-format file and actually allow you to do a post-mortem 'debugging
   session' on a dead program.  Since part of the PGTB file is the stack at
   the time of failure, enough information is available on local variables
   and so forth that you would be able to examine them after the fact, even
   if you weren't in the debugger when it died.