Re: [rfa] generate fully-qualified names for types

[David Carlton <carlton at kealia dot com>]

On Mon, 17 Nov 2003 11:52:09 -0500, Daniel Jacobowitz <drow@mvista.com> 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