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

[David Carlton <carlton at kealia dot com>]

On 18 Jan 2004 00:52:59 -0000, mec.gnu@mindspring.com said:

> local.cc has a class defined local to a function:

>   int foobar (int x)
>   {
>     class Local {
>     public:
>       int loc1;
>       char loc_foo (char c)
>       {
>         return c + 3;
>       }
>      };

>     Local l;
>     static Local l1;
>     ...
>    }

> I am in Foo.  I do "ptype l".

>   # gdb 6.0
>   (gdb) ptype l
>   type = class Local {
>     public:
>       int loc1;

>       char loc_foo(char);
>   }

>   # gdb HEAD 2004-01-16 02:35:50 UTC
>   (gdb) ptype l
>   type = class foobar__Fi.0::Local {
>     public:
>       int loc1;

>       char loc_foo(char);
>   }

> This is a regression from gdb 6.0.

> I think the problem is in this new code:

>   char *actual_class_name
>     = class_name_from_physname (dwarf2_linkage_name
>                                 (child_die));
>   if (actual_class_name != NULL
>       && strcmp (actual_class_name, name) != 0)
>   {
>      TYPE_TAG_NAME (type)
>        = obsavestring (actual_class_name,
>                        strlen (actual_class_name),
>                        &objfile->type_obstack);
>      xfree (actual_class_name);
>      need_to_update_name = 0;
>    }

> This is frustrating code.  It fires on gcc 2.95.3 and qualifies the
> class name with something that can't be found later.  But it doesn't
> fire on gcc 3.3.2 or gcc HEAD 2004-01-17.

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.

So what are the possible courses of action?

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.

2) Turn off the entire class name deduction machinery for GCC 2.95.3.

If we're insisting on preventing regressions, this is reasonable.  But
it would mean that users of GCC 2.95.3 -gdwarf-2 would have the old
behavior with nested classes, which seems like a shame.  And it would
add yet another special case to GDB.

3) Have GDB handle GCC 2.95.3 local class names specially somehow.

This would be the best of both worlds from a user point of view; it
would be the worst of both worlds from a maintenance point of view.

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.)


I tentatively would vote for option #1, and I say this not just out of
laziness - I think that users' experiences will be better if we do
option #1 than if we do option #2, and I don't like the maintenance
implications of option #3.  If we could come up with a good story
starting from option #4, though, that could also be worth considering.
What do other people think?

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.

David Carlton
carlton@kealia.com