From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14898 invoked by alias); 16 Apr 2003 17:59:37 -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 14820 invoked from network); 16 Apr 2003 17:59:36 -0000 Received: from unknown (HELO mailhub.lss.emc.com) (168.159.2.8) by sources.redhat.com with SMTP; 16 Apr 2003 17:59:36 -0000 Received: from emc.com (lul1179.lss.emc.com [168.159.33.179]) by mailhub.lss.emc.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h3GHtuV10145; Wed, 16 Apr 2003 13:55:56 -0400 (EDT) Message-Id: <200304161755.h3GHtuV10145@mailhub.lss.emc.com> To: Daniel Jacobowitz cc: gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: stabs and macro information In-Reply-To: Your message of "Wed, 16 Apr 2003 13:27:04 EDT." <20030416172704.GB16947@nevyn.them.org> References: <200304161558.h3GFwJV09359@mailhub.lss.emc.com> <20030416172704.GB16947@nevyn.them.org> Date: Wed, 16 Apr 2003 17:59:00 -0000 From: David Taylor X-SW-Source: 2003-04/txt/msg00169.txt.bz2 > Date: Wed, 16 Apr 2003 13:27:04 -0400 > From: Daniel Jacobowitz > > On Wed, Apr 16, 2003 at 11:58:19AM -0400, David Taylor wrote: > > Currently, when invoked with -gdwarf-2 -g3, gcc will record macro > > information in a .debug_macinfo elf section. And when presented with > > an executable containing macro information in a .debug_macinfo > > section, gdb will make use of it. > > > > Many companies, including EMC, still use stabs. So... it would be > > nice if the same was true of stabs. > > A more interesting question, to me, is why EMC still needs to use > stabs. They are an inferior debug format, extremely hard to parse or > extend. EMC does some processing of stabs via in house tools. I'm told that at one point before I started here that they switched to dwarf for a bit. And that the dwarf that was generated by GCC (and hence had to be handled by the local tools) changed a few times... They got tired of having to modify the in house tools, so they switched back to stabs. > GCC's and GDB's current implementations of DWARF-2 (and 3) are > somewhat lacking, but it's all fixable. I imagine we will eventually switch. But, as long as the gcc and gdb dwarf implementations are perceived as 'somewhat lacking', it's harder to make the case to management.