From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14889 invoked by alias); 2 May 2003 19:21:21 -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 14840 invoked from network); 2 May 2003 19:21:20 -0000 Received: from unknown (HELO zenia.red-bean.com) (12.222.151.100) by sources.redhat.com with SMTP; 2 May 2003 19:21:20 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h42JPvFq025393; Fri, 2 May 2003 14:25:57 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h42JPtVL025389; Fri, 2 May 2003 14:25:55 -0500 To: Andrew Cagney Cc: David Taylor , gdb@sources.redhat.com Subject: Re: macros, debug information, and parse_macro_definition References: <200304221640.h3MGelj05733@mailhub.lss.emc.com> <200304241512.h3OFCG518027@mailhub.lss.emc.com> <3EAE927E.4030005@redhat.com> From: Jim Blandy Date: Fri, 02 May 2003 19:21:00 -0000 In-Reply-To: <3EAE927E.4030005@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.95 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00019.txt.bz2 Andrew Cagney writes: > > These encodings are simple enough that I wouldn't expect them to > > change over time. > > I would think it more likely that there would be a bug, either in > > gcc's encoding of them or in gdb's processing of them. And if the > > code is duplicated, then both locations need to be modified to fix the > > bug -- with the attendant risk that someone will modify one and forget > > to modify the other. Or will modify it, but accidentally make it > > slightly different. > > > > I don't know how people would feel about having STABS have a > > description of the encoding combined with a caveat that the DWARF > > 2.0.0 spec is authoritative. I would certainly prefer that the STABS > > document remain self contained. > > I think this is a good strategy. It's already a ``gcc extension'', > and stealing an existing (known to be working) spec is always a good > strategy :-) > > Have you thought about link time information compression? One of the > complaints leveled at the macro stuff is the size of the resultant > debug info. Actually, I think that David's proposed representation will compress really well, with no new linker work. The linker's current behavior will do everything that's needed. Each entry in the .stab section is a fixed-size record; the textual portion of the stab is represented as an offset into the .stabstr section, which contains null-terminated strings. The .stabstr section is a SHT_STRTAB type section, which means that the linker will automatically factor out duplicates. So if two .stab entries have the same text, they'll end up pointing to the same bytes in .stabstr in the final executable. In David's proposed representation, #including a file into many different .o files will produce stabs entries with identical strings, so they'll all get factored out nicely. All this is completely independent of the BINCL/EINCL -> EXCL compression the linker also does for STABS, to factor out duplicated entries from the .stab section itself.