From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26292 invoked by alias); 29 Apr 2003 14:55:59 -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 26284 invoked from network); 29 Apr 2003 14:55:59 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 29 Apr 2003 14:55:59 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 366CA2B2F; Tue, 29 Apr 2003 10:55:58 -0400 (EDT) Message-ID: <3EAE927E.4030005@redhat.com> Date: Tue, 29 Apr 2003 14:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Taylor Cc: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00323.txt.bz2 > > 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. Andrew