From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15699 invoked by alias); 16 Dec 2009 03:01:32 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 15138 invoked by uid 22791); 16 Dec 2009 03:01:28 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Tom Tromey Cc: Daniel Jacobowitz , archer@sourceware.org Subject: Re: Initial psymtab replacement results In-Reply-To: Tom Tromey's message of Tuesday, 15 December 2009 16:38:58 -0700 References: <20091211235901.GA16889@caradoc.them.org> <20091214230947.GA31362@caradoc.them.org> Message-Id: <20091216030118.A676A1D7@magilla.sf.frob.com> Date: Wed, 16 Dec 2009 03:01:00 -0000 X-SW-Source: 2009-q4/txt/msg00108.txt.bz2 > I think we ought to change GCC to drop the .debug_pub* sections (and > maybe .debug_aranges), at least on Linux. AFAIK they aren't used by > anything, and indeed are barely usable due to historic bugs -- so they > are just wasting time and space. A correct .debug_aranges is trivially deduced from the .debug_info data. So any DWARF rewriter can (and will) easily emit this from scratch (and correct, and maybe consolidating the uselessly many entries for the same CU with adjacent address ranges that just bend around a zillion 2-byte section alignment holes). (Perhaps there is something easy and kosher to do that GDB could use as an indicator of a .debug_aranges worth using.) With .debug_pub* it has always been my impression that the extraction from the DIE tree is not fully generic. That is, it at least assumes some language-specific knowledge to construct foo::bar names and the like. I've never been entirely clear on if it's even entirely knowable just from very simple language knowledge as opposed to encoding some choices or extra knowledge the compiler had. As a hacker of supposedly fully-generic DWARF tools, I am much happier with the idea of index sections that are described purely in terms of a generic extraction from the DIE trees without regard to any knowledge outside the DWARF spec proper. Thanks, Roland