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

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

[Michael Elizabeth Chastain]

David Carlton writes:

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

This has been working fine for me with gdb HEAD, suite HEAD, gcc HEAD,
-gdwarf-2 since 2004-01-23.  I got some FAILs on 2004-01-18 and
2004-01-19.

Do you really need gcc 3.5.0 20040119?
Can you try gcc 3.5.0 20040315 for example?

> I really hate the way we test our DWARF 2 reader - there's no way to
> generate the debug info by hand to give a particular scenario, so
> instead we have to hope that we can find the magic version of GCC and
> magic way of writing a test case to trigger the bug in question.
> Sigh.

Can we write a gdb.dwarf-2 that looks like gdb.stabs,
with assembly language input in it?

Michael C

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

[Daniel Jacobowitz]

On Mon, Mar 15, 2004 at 09:39:21PM -0500, Michael Chastain wrote:
> David Carlton writes:
> 
>   ptype CClass::NestedClass
>   There is no field named NestedClass
>   (gdb) FAIL: gdb.cp/namespace.exp: ptype CClass::NestedClass
> 
> This has been working fine for me with gdb HEAD, suite HEAD, gcc HEAD,
> -gdwarf-2 since 2004-01-23.  I got some FAILs on 2004-01-18 and
> 2004-01-19.

Have you run it since I committed the process_structure_scope patch on
Saturday?  I won't have time to really parse David's explanation for a
couple of days but it sounds like I broke this.

> 
> Do you really need gcc 3.5.0 20040119?
> Can you try gcc 3.5.0 20040315 for example?
> 
> > I really hate the way we test our DWARF 2 reader - there's no way to
> > generate the debug info by hand to give a particular scenario, so
> > instead we have to hope that we can find the magic version of GCC and
> > magic way of writing a test case to trigger the bug in question.
> > Sigh.
> 
> Can we write a gdb.dwarf-2 that looks like gdb.stabs,
> with assembly language input in it?
> 
> Michael C
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[David Carlton]

On Mon, 15 Mar 2004 21:39:21 -0500 (EST), mec.gnu@mindspring.com
(Michael Elizabeth Chastain) said:

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

> This has been working fine for me with gdb HEAD, suite HEAD, gcc HEAD,
> -gdwarf-2 since 2004-01-23.  I got some FAILs on 2004-01-18 and
> 2004-01-19.

Hmm.  Well, I'm checking out gcc-3_4-branch as we speak, so we'll see
how it goes.  (And at some point I'll update my mainline GCC, too.)
As Daniel says, this may be a very recent bug in GDB, so you may not
have seen it.  (Or it may be that the GCC I'm using is generating
valid DWARF-2 which happens to be different from the current GCC
snapshot, for that matter.)

>> I really hate the way we test our DWARF 2 reader - there's no way
>> to generate the debug info by hand to give a particular scenario,
>> so instead we have to hope that we can find the magic version of
>> GCC and magic way of writing a test case to trigger the bug in
>> question.  Sigh.

> Can we write a gdb.dwarf-2 that looks like gdb.stabs, with assembly
> language input in it?

That's a good idea; I'll think about that.

David Carlton
carlton@kealia.com

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

[Michael Elizabeth Chastain]

> Have you run it since I committed the process_structure_scope patch on
> Saturday?  I won't have time to really parse David's explanation for a
> couple of days but it sounds like I broke this.

No, my last spin was for Monday, 2004-03-08.

I have another spin in progress for Sunday, 2004-03-14 15:04:08 UTC, but
you committed that patch on 2004-03-14 21:08:24 UTC so it's not in my
current spin.  Rats.

Michael C

gcc 3.4 regression in gdb.cp/namespace.exp

[David Carlton]

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

Just to double-check, I reverted my recent dwarf2read.c patch (I
tested in with that GCC a week ago, but who knows), and it still
fails.  Daniel, might it be an issue with a recent patch of yours?  (I
have a more specific guess below.)

Here's some more info: the classes in question are defined as follows:

  class CClass {
  public:
    int x;
    class NestedClass {
    public:
      int y;
    };
  };

The debug info that I'm getting looks like this:

	.uleb128 0x17	# (DIE (0x480) DW_TAG_structure_type)
	.long	0x505	# DW_AT_sibling
	.long	.LASF2	# DW_AT_name: "CClass"
	.byte	0x1	# DW_AT_declaration
	.uleb128 0x18	# (DIE (0x48a) DW_TAG_structure_type)
	.long	.LASF1	# DW_AT_name: "NestedClass"
	.byte	0x4	# DW_AT_byte_size
	.byte	0x1	# DW_AT_decl_file
	.byte	0x5e	# DW_AT_decl_line
	.uleb128 0x8	# (DIE (0x492) DW_TAG_member)
	.ascii "y\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x60	# DW_AT_decl_line
	.long	0x19e	# DW_AT_type
	.byte	0x2	# DW_AT_data_member_location
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0x0

(Rest of CClass::NestedClass definition omitted.)  Then, later on, we
see:

	.uleb128 0x7	# (DIE (0x6ec) DW_TAG_structure_type)
	.long	0x75d	# DW_AT_sibling
	.long	0x480	# DW_AT_specification
	.byte	0x4	# DW_AT_byte_size
	.byte	0x1	# DW_AT_decl_file
	.byte	0x5b	# DW_AT_decl_line
	.uleb128 0x8	# (DIE (0x6f8) DW_TAG_member)
	.ascii "x\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x5d	# DW_AT_decl_line
	.long	0x19e	# DW_AT_type
	.byte	0x2	# DW_AT_data_member_location
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0x0

(Rest of CClass definition omitted.)

So we have a die giving a declaration for CClass which in turn
contains a die giving a definition for CClass::NestedClass.  Which in
turn suggests that the loop in process_structure_scope should be run
even if the current DIE is a declaration.

I'll fiddle around with an appropriate patch either later today or
tommorow.

I really hate the way we test our DWARF 2 reader - there's no way to
generate the debug info by hand to give a particular scenario, so
instead we have to hope that we can find the magic version of GCC and
magic way of writing a test case to trigger the bug in question.
Sigh.

David Carlton
carlton@kealia.com

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

[David Carlton]

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