From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30165 invoked by alias); 17 Apr 2003 16:46:48 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29987 invoked from network); 17 Apr 2003 16:46:48 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 17 Apr 2003 16:46:48 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 196CXI-00020Y-00; Thu, 17 Apr 2003 11:46:56 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 196CX5-0002EB-00; Thu, 17 Apr 2003 12:46:43 -0400 Date: Thu, 17 Apr 2003 16:46:00 -0000 From: Daniel Jacobowitz To: David Taylor Cc: Daniel Berlin , gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: stabs and macro information Message-ID: <20030417164643.GA8469@nevyn.them.org> Mail-Followup-To: David Taylor , Daniel Berlin , gcc@gcc.gnu.org, gdb@sources.redhat.com References: <2EE8F46C-704A-11D7-A180-000393575BCC@dberlin.org> <200304171639.h3HGdNA23643@mailhub.lss.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304171639.h3HGdNA23643@mailhub.lss.emc.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00195.txt.bz2 On Thu, Apr 17, 2003 at 12:39:21PM -0400, David Taylor wrote: > > > They are an inferior debug format, extremely hard to parse or > > > extend. GCC's and GDB's current implementations of DWARF-2 (and 3) are > > > somewhat lacking, but it's all fixable. > > > > And, more importantly, in the process of being fixed. > > :) > > Ummm, I would have to disagree about the first part. > > STABS is pretty easy to extend. I haven't done the GDB part yet; but, > while I imagine it will take longer to do than the GCC part, I don't > expect it to take a long time and I expect that the bulk of the time > will be becoming enough familiar with the macro table stuff in GDB to > make the right calls. How to modify GDB's STABS parser looks pretty > straightforward. No. Your extensions are an example of a kind which would be easy to add; but for some C++ concepts which DWARF-2 can express, it would be a heck of a lot harder. Inline functions, templates, namespaces (Sun has recent extensions for at least this one), virtual inheritance (we can do this now but you'll see what I mean about gross extensions if you look at how!), et cetera. A better example is .debug_loc; location lists in stabs would be extremely difficult to integrate into the stabs text format. > That the problems with GCC's and GDB's implementations of DWARF are > being addressed is important. > > I feel that saying that DWARF is a superior *format* is irrelevant if > the implementation is not superior. As the implementation improves > and the size of the DWARF info decreases, people will be more likely > to embrace DWARF. The size of the information is an issue for us. These are not the only implementations in the world. Sadly, right now they aren't close to the best, either. There are some interesting existance proofs, in e.g. the Intel tools. As for text vs binary - there are at least two good DWARF-2 dumpers, readelf and dwarfdump; I find their output a whole lot easier to make sense of than stabs. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer