From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12394 invoked by alias); 28 Jan 2004 18:51:23 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12365 invoked from network); 28 Jan 2004 18:51:21 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 28 Jan 2004 18:51:21 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 114C1C6D8; Wed, 28 Jan 2004 10:51:21 -0800 (PST) To: gdb-patches@sources.redhat.com Subject: Re: [rfa] classes, partial symtabs, and DW_AT_specification References: <20040125170031.GA10709@nevyn.them.org> From: David Carlton Date: Wed, 28 Jan 2004 18:51:00 -0000 In-Reply-To: <20040125170031.GA10709@nevyn.them.org> (Daniel Jacobowitz's message of "Sun, 25 Jan 2004 12:00:31 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg00723.txt.bz2 On Sun, 25 Jan 2004 12:00:31 -0500, Daniel Jacobowitz said: > On Fri, Jan 23, 2004 at 04:40:48PM -0800, David Carlton wrote: >> This is a serious design problem with our psymtab structure, which >> we've known about for a while. Either we need to add into it a >> fast way to follow DW_AT_specification links _and_ then figure out >> the parent of the die at the other end, or we need help from the >> compiler, or something. In any event, any correct solution would >> be a major undertaking; the best way to deal with the situation for >> now is to use demangled names when we run into this situation, just >> like we would if the compiler weren't generating DW_TAG_namespace >> at all. > I have no objection to this as a workaround, although it makes me feel > a bit filthy :) I know the feeling... >> OK to commit? I guess I need symtab approval, though Daniel should >> feel free to chime in as well. :-) And at some point we really need to >> develop a plan of attack for DWARF-2 partial symbols - what >> improvements can we do without GCC's help, what help do we want from >> GCC? > We don't need anything from GCC. We have everything we need already; > we just need to do things (very) differently. Yeah. For the issue I ran into, it's probably not _too_ hard to solve: we could build up a die->parent table that only covered the dies that we would want to parse while reading the psymtabs - the spec die that I'm looking for should already be such a die. But using this as an excuse to step back and think about how we want dwarf2 psymtabs to work in an ideal world would certainly be a good idea. > I am working on inter-CU reference support again; if we can't find > parents then there's no point in building psymtabs, since we won't > be able to cope with the first reference to another CU that isn't > nested directly under the CU DIE. Ah. > With a little tuning, I think this is a solvable problem. It will > probably take a speed hit, but smaller debug info will hopefully > make up for a lot of that. And then, if someone implements > .debug_info_index, we can use that for psymtabs instead. Do you have a reference for .debug_info_index? I tried searching for it, but nothing turned up; I couldn't find an archive for the dwarf2 mailing list. David Carlton carlton@kealia.com