Re: symtab/1516: [regression] local classes, gcc 2.95.3, dwarf-2

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Jan 23, 2004 at 11:20:00AM -0800, David Carlton wrote:
> So here's the deal.  The code in question is trying to figure out the
> name of the class starting from the mangled name of one of its members
> - in general, with GCC < 3.4, we don't have any other way to figure
> out the names of nested classes.
> 
> The problem is that the demangled name of a local class doesn't look
> like the user expects: there's this extra "foobar_Fi.0::" bit stuck in
> front.
> 
> The reason why this only crops up in 2.95.3 is that GCC 3.x doesn't
> include the mangled names of members of local classes in the debug
> info!  I'll have to think about the implications of that (does anybody
> know why that was done?), but it means that we don't see that problem
> with 3.x.

Blech... well, soon we won't care for 3.x, between DW_TAG_namespace and
gdb improvements.

> 1) Leave things alone.
> 
> This doesn't seem like the end of the world to me - it means that, if
> a user is using GCC 2.95.3 -gdwarf-2, then GDB 6.1 will work better
> than 6.0 when dealing with nested classes but worse when dealing with
> local classes.  That sounds like an okay tradeoff - nested classes
> are, I think, more important than local classes.  Also, the way in
> which GDB 6.1 is working worse doesn't seem _so_ awful.

No real objection.

> 4) Change the demangler's output for local class names.
> 
> If the class were named "((function foobar))::Local" instead of
> "foobar__Fi.0::Local", the output might be more acceptable.  (But
> doing "ptype Local" would still fail.)

If we are going to change the demangler, the proper output is probably
foobar(int)::Local.  I already have code on drow-cplus-branch to parse
this correctly as a name local to function foobar(int).  The only
reason I haven't done this so far is that then we have to figure out
how to get the type associated with the block for the function, since
they may or may not come in the right order.  This requires all sorts
of to-the-side lists.  It might be worthwhile.

> Incidentally, this raises another question: why haven't my changes
> fixed PR 482 (for GCC 3.x), the nested local classes bug?  I've added
> that to my TODO list, though there are other things that are more
> urgent for me to work on.

Now, _that_ is a good question.  I may look into it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer