From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5463 invoked by alias); 22 Sep 2003 22:16:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5455 invoked from network); 22 Sep 2003 22:16:24 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 22 Sep 2003 22:16:24 -0000 Received: by zenia.home (Postfix, from userid 5433) id 27B1D20762; Mon, 22 Sep 2003 17:13:10 -0500 (EST) To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [6.0] PROBLEMS and NEWS References: <3F6CBFA5.7060308@redhat.com> <3F6F499E.7020102@redhat.com> From: Jim Blandy Date: Mon, 22 Sep 2003 22:16:00 -0000 In-Reply-To: <3F6F499E.7020102@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00485.txt.bz2 Looks good, just some picky comments: Andrew Cagney writes: > +* New back-trace mechanism (includes DWARF 2 Call Frame Identification). > + > +DWARF 2's Call Frame Identification makes available compiler generated s/Identification/Information/; that's what the spec calls it. > +information that more exactly describes the program's run-time stack. > +By using this information, GDB is able to provide more robust stack > +back-traces. The GDB manual uses "backtrace" throughout, never "back-trace". There are other uses of "back-trace" in the proposed text. > +* DWARF 2 Location Expressions > + > +DWARF 2 Location Expressions allow the compiler to more exactly > +describe the location of variables to the debugger. It'd be nice to give some indication of why the user would care about this, like: "Taken together with Dwarf 2 Call Frame Information, location expressions give GDB the information it needs to debug optimized code much more effectively."