From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7727 invoked by alias); 21 Nov 2002 06:40:34 -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 7713 invoked from network); 21 Nov 2002 06:40:33 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 21 Nov 2002 06:40:33 -0000 Received: from dberlin.org (h-69-3-5-6.MCLNVA23.covad.net [69.3.5.6]) by mail.cdt.org (Postfix) with ESMTP id 28BDF4900DF; Thu, 21 Nov 2002 01:39:44 -0500 (EST) Received: from [192.168.1.2] (HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.0.1) with ESMTP-TLS id 1630175; Thu, 21 Nov 2002 01:40:27 -0500 Date: Wed, 20 Nov 2002 22:40:00 -0000 From: Daniel Berlin To: Daniel Jacobowitz Cc: Jim Blandy , Steven Johnson , , Subject: Re: DWARF-2 + discarded link-once sections (was Re: Internal error in GDB) In-Reply-To: <20021121044940.GA20705@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-11/txt/msg00307.txt.bz2 > > Is there *no* other way to tell whether the debug info refers to a > > discarded section? Can we add logic to BFD to tell us about this? > > There really isn't. It would be nice to discard it at link time. But > this is, well, really complicated. It's no so much complicated as it is a pain in the ass to implement (big difference. One could probably explain how to do it to a 12 year old. But then he'd not want to implement it either. :P) > In my inexpert opinion at least. > (This is a similar problem to coalesced symbols in Darwin, as I > understand it?) > > Hmm, maybe it isn't as bad as all that for DWARF-2. If we get a die > with low_pc and high_pc attributes referring to a discarded section, we > could discard the die and all its children. But there might be > _references_ to that die somewhere... this requires general purpose > DWARF-2 editing that we don't really have yet. It's not that hard to do, if you do it with a worklist rather than trying to fix it up in one or two or n fixed passes. The general solution is like this: While walking over dies: 1. record what other dies they reference (convert to absolute offset from start of debug_info). An inverted index mapping absolute offsets to dies that reference them is what we really want. Ignore all sibling links, it's quicker to just rewrite them all then fix them up. 2. Every time we decide to remove a die, push everything currently in the inverted index for that die's offset onto the fixup worklist, and remove them from the inverted index. Mark the die as needing to be fixed up (seperately. I'm assuming it would take O(n) time to check whether it's on the worklist or not, which we want to avoid later on). Determine the new offsets for all dies, regardless of whether they have references *inside* them needing to be fixed up. Store this in an index of some sort. Lastly, while there are still things on the fixup worklist: 1. Fix the die references we can. If there are dies it references that need to be fixed up themselves, put it back on the end of the worklist, if not, it's a done die. At the end, rewrite the sibling links. The worklist will terminate unless you have circular die references (which you shouldn't), since there must be some die on the list not pointing to dies needing to be fixed up. Of course, it might be O(n^2) iterations, but you can avoid this through going through dies in topological sorted order, the same way you would do on a flowgraph. > > I'm CC'ing this over to binutils, because Alan and/or Jakub would have > a much better feel for whether this is possible than I do. > > > Could we generate custom GNU Dwarf 2 information so as to allow GDB to > > detect a removed section? That is, if we *ask* the linker to tell us, > > will it? We could make all debug info in linkonce sections children > > of new DW_TAG_GNU_linkonce dies, with magic attributes that let us > > detect whether they've been discarded. > > This could work too but it would be nice to avoid it. Not just nice. It should be that we shouldn't do it unless their is some *incredibly* compelling reason to do so. Let's *please* avoid adding a kludge when we know a solution to the problem, it's a solution we want for other reasons as well, and is maybe 3x the work you'll do anyway. Think of the ramifications of doing a DW_TAG_GNU_linkonce. You'd screw other linkers and debuggers that currently support linkonce. Some will later copy the whole DW_TAG_linkonce, to boot. So when we want to throw it out in 2 years when someone finally implements this the right way, we won't be able to because those others will scream bloody murder. We'll then be stuck with this kludge for 5 years anyway because that's when the majority of people got around to upgrading to something that doesn't generate or use it. Is it *really* worth it? If nobody wants to implement dwarf2 editing, just do nothing, rather than implement a kludge that we'll be stuck with. > We were > discussing .debug_info.gnu.linkonce.* sections at one point; did we > abandon that idea because there were too many of them, or was there > some other problem? > >