From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15022 invoked by alias); 29 Apr 2003 17:13:23 -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 15015 invoked from network); 29 Apr 2003 17:13:21 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 29 Apr 2003 17:13:21 -0000 Received: from [192.168.1.159] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b4) with ESMTP-TLS id 3750891; Tue, 29 Apr 2003 13:13:20 -0400 Date: Tue, 29 Apr 2003 17:13: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: gdb@sources.redhat.com To: Keith Walker From: Daniel Berlin In-Reply-To: <4.3.2.7.2.20030429170707.02ac6180@mhsun1.maidenhead.arm.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00331.txt.bz2 On Tuesday, April 29, 2003, at 12:16 PM, Keith Walker wrote: > At 11:55 29/04/2003 -0400, Daniel Berlin wrote: >> 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. > > I'm not sure whether your comment is about macro info in general or > about macro info in DWARF2. > > Unfortunately, for DWARF2 debugging information, I don't think it is > quite so easy in that the macro information can include file start/end > entries which refer to file entries in the associated line number > information - I'm aware, i wrote GCC's DWARF2 macro info support. :) > so you would also have to do something about merging the line number > tables as well; This is also trivial, since it's just going to require updating an attribute on all the DIEs, not moving/removing DIE's (which is the only real thing that generates problems in merging DWARF2 info). > and hence update all other entries that refer to the file entries. Still trivial compared to what you have to do for DWARF2 info in general. > > Keith >