From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15045 invoked by alias); 18 Nov 2003 17:51:36 -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 15038 invoked from network); 18 Nov 2003 17:51:35 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 18 Nov 2003 17:51:35 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 0D1F4C6AC; Tue, 18 Nov 2003 09:51:35 -0800 (PST) To: gdb-patches@sources.redhat.com Cc: Elena Zannoni , Jim Blandy Subject: Re: [rfa] generate fully-qualified names for types References: <20031117165209.GA15811@nevyn.them.org> From: David Carlton Date: Tue, 18 Nov 2003 17:51:00 -0000 In-Reply-To: <20031117165209.GA15811@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 17 Nov 2003 11:52:09 -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: 2003-11/txt/msg00382.txt.bz2 On Mon, 17 Nov 2003 11:52:09 -0500, Daniel Jacobowitz said: > On Wed, Nov 12, 2003 at 10:53:01AM -0800, David Carlton wrote: >> * lookup_transparent_type poses particular problems. That function >> deals with the situation where a class has an abstract declaration >> but not a full definition. Unfortunately, in this situation we >> don't have any member functions around to demangle, which means that >> we generate symbols with the wrong name. (If GCC doesn't generate >> DW_TAG_namespace, that is.) Oops. I have a hack on my branch that >> increases the number of cases where we get the right symbol back, >> but it really is a hack. I'm not sure that there's anything we can >> do about this without more help from GCC. (Hmm: why do we generate >> symbols associated to those declarations in the first place? Maybe >> that's worth thinking about.) You'll notice that gdb.cp/rtti.exp > We need them. You can have this, and often do in GDB: > struct Foo; > extern void foofoo(struct Foo *); > We have to have a type associated with struct Foo in order to print > the type of this function, call it, et cetera. Yeah. And I guess there might not be a real definition anywhere in some circumstances - e.g. the real definition could only show up in a library without debug info. It's an unfortunate situation. I should have been more proactive about getting DW_TAG_namespace into GCC 3.4. Maybe it will still happen - I hear that Devang Patel is working on it. > Are the failures in templates.exp real failures caused by > internal-to-GDB differences in output, or are they caused by > tolerable changes in the output? I saw mostly the latter when > working with stabs. I think the changes are tolerable. Some spaces get added, some parentheses get added, some const chars turn into char consts. Only the latter will have any practical effect at all. > I would appreciate it if you could prepare a matching patch to > templates.exp which either fixes the failures if they are output > issues, or adds KFAIL patterns otherwise. I know it's a nuisance but I > do not want to leave failures that we aren't going to fix in the short > term. > A KFAIL for the rtti.exp test would be an added bonus. Will do, for both. > Oh, and as I said elsewhere I don't think that "fixing" the > demangler is a worthwhile exercise. Yeah, I know - we've argued about this enough before. :-) Like I said, the main sticking point for me is the RTTI information. But I suppose the proper solution would be for us to get that information some other way. For example, we could build up a table of vptrs (mapping minimal symbols to classes, or even addresses to classes), and have the RTTI info use that table instead of the demangled names. Or, for that matter, we could try to generate the demangled names of the vptrs without using the demangler, if possible. > OK. By the way, I don't intend for GCC to generate .debug_pubtypes, > but I do intend for it to generate something twice proposed on the > dwarf2 list: .debug_info_index. Which, as you say, looks "an awful lot > like the full symbol reader" - it uses DIEs. Interesting. >> @@ -214,22 +225,15 @@ cp_set_block_scope (const struct symbol >> >> if (SYMBOL_CPLUS_DEMANGLED_NAME (symbol) != NULL) >> { >> -#if 0 >> - /* FIXME: carlton/2003-06-12: As mentioned above, >> - 'processing_has_namespace_info' currently isn't entirely >> - reliable, so let's always use demangled names to get this >> - information for now. */ >> - >> if (processing_has_namespace_info) >> { >> block_set_scope >> - (block, obsavestring (processing_current_namespace, >> - strlen (processing_current_namespace), >> + (block, obsavestring (processing_current_prefix, >> + strlen (processing_current_prefix), >> obstack), >> obstack); >> } >> else >> -#endif >> { >> /* Try to figure out the appropriate namespace from the >> demangled name. */ > How many of these prefixes end up being identical - is it usually close > to one, or do we get one copy for each method in a class, et cetera? > We could use a bcache for this if we have duplicates. Lots of duplicates - all the methods in a class could share a prefix, all of the free functions defined in a namespace could share a prefix, etc. Having said that, I'd prefer not to use a bcache - I bet that the memory would get lost in the noise, and our memory-management story is already complex enough as it is. Hmm. I guess it wouldn't be that bad. The function's caller has access to the objfile in question, so we could just add a name_bcache member to struct objfile. (And eventually think about the division of labor between it and the demangled name hashtable...) > Otherwise I have no complaints about this patch. The non-symtab parts > are OK and the rest looks good to me. Thanks. Then I'll prepare a testsuite patch for the failures and look into using a bcache. David Carlton carlton@kealia.com