This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gcc 3.4 regression in gdb.cp/namespace.exp
- From: David Carlton <carlton at kealia dot com>
- To: gdb <gdb at sources dot redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>,Jim Blandy <jimb at redhat dot com>, Elena Zannoni <ezannoni at redhat dot com>
- Date: Tue, 16 Mar 2004 10:25:39 -0800
- Subject: Re: gcc 3.4 regression in gdb.cp/namespace.exp
- References: <yf2brmx3aia.fsf@hawaii.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