From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25013 invoked by alias); 17 Apr 2003 16:39:32 -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 24947 invoked from network); 17 Apr 2003 16:39:31 -0000 Received: from unknown (HELO mailhub.lss.emc.com) (168.159.2.8) by sources.redhat.com with SMTP; 17 Apr 2003 16:39:31 -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 h3HGdNA23643; Thu, 17 Apr 2003 12:39:23 -0400 (EDT) Message-Id: <200304171639.h3HGdNA23643@mailhub.lss.emc.com> To: Daniel Berlin cc: Daniel Jacobowitz , gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: stabs and macro information In-Reply-To: Your message of "Wed, 16 Apr 2003 16:29:54 EDT." <2EE8F46C-704A-11D7-A180-000393575BCC@dberlin.org> References: <2EE8F46C-704A-11D7-A180-000393575BCC@dberlin.org> Date: Thu, 17 Apr 2003 16:39:00 -0000 From: David Taylor X-SW-Source: 2003-04/txt/msg00194.txt.bz2 > Date: Wed, 16 Apr 2003 16:29:54 -0400 > From: Daniel Berlin > > On Wednesday, April 16, 2003, at 01:27 PM, Daniel Jacobowitz wrote: > > > A more interesting question, to me, is why EMC still needs to use > > stabs. > I didn't want to get into this argument, as there are companies that > have valid reasons not to use DWARF2 given the current implementations, > particularly those compaonies that end up with 1 gigabyte with stabs > info, and 5 gigabytes with dwarf2 info, or something like that. Agreed. I was talking earlier yesterday with the author of some of the internal tools that manipulate STABS. At least part of the reason for preferring STABS is the sheer size of the DWARF information. I believe that eliminating duplication of information so that DWARF is comparable in size to STABS will go a long way towards reducing people's resistance to DWARF. Stability in how information is encoded will also help. Another complaint I heard was how DWARF is a mixture of binary and text whereas STABS is just text -- therefore making STABS easier to parse by Perl. [I believe that the person making this complaint feels much more comfortable with Perl than with C.] > However, I was going to ask whether the cost of *adding* more features > to the STABS implementations in gdb and gcc is worth the future > maintenance cost at this point in the life of STABS. The GCC cost seems low. Factoring out the interrupts and related items that occurred during the implementation, testing, and debugging, I would guess that it was less than one day to do all three. Let's see, I modified 3 files, c-lex.c, dbxout.c, and stab.def. * c-lex.c (init_c_lex): Set cb->define and cb->undef for DBX_DEBUG, too. * dbxout.c (dbxout_define, dbxout_undef): New functions; handle macro define and undef for STABS. (dbx_debug_hooks): Initialize define and undef fields to dbxout_define and dbxout_undef, respectively. * stab.def (N_MAC_DEFINE, N_MAC_UNDEF): New entries. In c-lex.c, I modified 1 (one!) if statement to add DBX_DEBUG as a case where you want to initialize cb->define and cb->undef. Not a big deal. In stab.def, I've already posted the lines that got added. Also trivial. In dbxout.c, I added two simple functions and arranged for them to be called. Taking dbxout_define, here's how simple the body of it is: if (debug_info_level >= DINFO_LEVEL_VERBOSE) { fprintf (asmfile, "%s", ASM_STABS_OP); output_quoted_string (asmfile, buffer); fprintf (asmfile, ",%d,0,%d,0\n", N_MAC_DEFINE, lineno); } That is it. Nothing more. And dbxout_undef is *VERY* similar. Given how easy it is and given that I don't think that STABS is going to go away anytime soon, I think it's worth it. Perhaps I'm wrong. [But, it's worth it to us. And even if the change, when it's eventually posted, is not accepted, we will likely maintain this difference as long as we continue to use STABS.] > > 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. I think that a large part of STABS' problem, historically, is that . it was easy to extend, . there was no one charged with resolving conflicts between conflicting extensions, and . it was undocumented. [Because it was undocumented, in a conflict between a STABS producer and a STABS consumer, you couldn't say definitively who was right and who was wrong. We live with the result.] 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. > > > > -- > > Daniel Jacobowitz > > MontaVista Software Debian GNU/Linux Developer Later, David -- David Taylor dtaylor@emc.com