Re: gcc 3.4 regression in gdb.cp/namespace.exp

[David Carlton <carlton@kealia.com>]

On Mon, 15 Mar 2004 16:23:41 -0800, David Carlton <carlton@kealia.com> said:

> I just ran the testsuite with g++ (GCC) 3.5.0 20040119 (experimental)
> (which is right after 3.4 branched), and I get a regression on
> gdb.cp/namespace.exp, on both mainline and 6.1.

>   ptype CClass::NestedClass
>   There is no field named NestedClass
>   (gdb) FAIL: gdb.cp/namespace.exp: ptype CClass::NestedClass

I've done some poking around; here's the deal.

* I haven't checked with new GCC versions (I can't connect to
  savannah.gnu.org), but I have verified that Daniel's patch caused the
  regression.

* Recall that the setup is:

    Die 1: declaration for CClass.
       Die 2: definition for CClass::NestedClass.

  (Whether or not it's a good idea for GCC to generate DIEs like this
  is another matter, but it is, at least with the snapshot that I was
  using, and it seems to be legal.)

  When reading Die 1 (both within read_structure_type and within
  process_structure_scope), GDB notices that the die is a declaration,
  so it doesn't bother looking at Die 2.

* This behavior is, however, the same as the old behavior of
  read_structure_scope.  So how could Daniel's patch have caused a
  regression?  The answer: further down we have:

    Die 3: DW_TAG_reference_type
      referring to Die 2 above.

  So we call read_tag_reference_type, which calls die_type, which
  calls tag_type_to_type, which calls read_type_die.  Which used to
  call read_structure_scope (i.e. read_structure_type +
  process_structure_scope), but now only calls read_structure_type.

Pretty subtle - I certainly wouldn't have been able to figure this out
from looking at the source code alone.  (But that's why we have GDB!)

So what's the correct fix here?  I tend to think that the code would
be easier to understand if we only generated symbols while going
through the code in the obvious tree order (calling functions named
process_XXX, ideally), instead of while following various
cross-references (which we would only do via functions named read_XXX,
ideally).  Is that a reasonable hope?  If so, it seems like the
correct fix would be to change process_structure_scope to call
process_die on all of its children, whether or not the current die is
a declaration.  I'll play around with a patch like that - it should be
safe, I hope, since process_structure_scope is only called from
process_die, so we shouldn't be generating symbols twice.

David Carlton
carlton@kealia.com