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.