From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27014 invoked by alias); 29 Apr 2003 15:55:19 -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 27002 invoked from network); 29 Apr 2003 15:55:19 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 29 Apr 2003 15:55:19 -0000 Received: from [192.168.1.159] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b4) with ESMTP-TLS id 3750703; Tue, 29 Apr 2003 11:55:17 -0400 Date: Tue, 29 Apr 2003 15:55:00 -0000 Subject: Re: macros, debug information, and parse_macro_definition Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Taylor , gdb@sources.redhat.com To: Andrew Cagney From: Daniel Berlin In-Reply-To: <3EAE927E.4030005@redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00327.txt.bz2 On Tuesday, April 29, 2003, at 10:55 AM, Andrew Cagney wrote: > >> 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. It's trivial to do macro information compression, unlike normal dwarf2 info compression, because the macro info has no references. It is what it is. With a smart algorithm (it's a bit tricky to keep the semantics the same after merging all the macro infos), you could simply take all the macro infos, merge them, make one macro info, and point all the debug sections at it. I think, anyway. > > Andrew > >