From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9285 invoked by alias); 25 Jan 2004 17:00:42 -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 9277 invoked from network); 25 Jan 2004 17:00:40 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 25 Jan 2004 17:00:40 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Akncd-0002pf-KK; Sun, 25 Jan 2004 12:00:31 -0500 Date: Sun, 25 Jan 2004 17:00:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb-patches@sources.redhat.com, Elena Zannoni Subject: Re: [rfa] classes, partial symtabs, and DW_AT_specification Message-ID: <20040125170031.GA10709@nevyn.them.org> Mail-Followup-To: David Carlton , gdb-patches@sources.redhat.com, Elena Zannoni References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00662.txt.bz2 What a coincidence you should raise this subject... :) On Fri, Jan 23, 2004 at 04:40:48PM -0800, David Carlton wrote: > When building the partial symbol table for this file, we look for > definitions of classes; but, when we see the definition for N::C, the > only way we know from the debug info that we're within namespace N is > by following DW_AT_specification. Which we can't do with our > psymtabs. > > 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 :) > 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. Coincidentally, we already have another reason to do things differently. 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. 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer