debug/9717: regression: g++ -gstabs+ emits unwanted stabs for base class

[mec at shout dot net]

>Number:         9717
>Category:       debug
>Synopsis:       regression: g++ -gstabs+ emits unwanted stabs for base class
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 16 18:06:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     mec@shout.net
>Release:        gcc version 3.3 20030214 (prerelease)
>Organization:
>Environment:
target=i686-pc-linux-gnu, host=native, osversion=red-hat-8.0
gcc=gcc-3_3-branch%20030214, binutils=2.13.2.1, libc=vendor
gformat=-gstabs+

This happens with both gcc-3_3-branch and HEAD.
This does not happen with gcc 3.2.2 (hence, regression error).
>Description:
The debug info for a class contains unnamed opaque fields for the base classes.  gdb handles these unnamed opaque fields but this leads to funny looking output and user confusion.

program under test:

  struct A
  {
    int a;
    A (int aa): a (aa) {}
  };

  struct B: public A
  {
    int b;
    B (int aa, int bb): A (aa), b(bb) {}
  };

  int
  main (int argc, char **argv)
  {
    A *a = new B(42, 1729);
    B *b = (B *) a;

    return 0;  /* breakpoint spot: casts.exp: 1 */
  }

Compile with:

  g++ -S -gstabs+ casts.cc

This generates the following stab:

  .stabs "B:Tt(1,10)=s8!1,020,(1,1);:(1,11)=s4;,0,32;b:(0,1),32,32;...",128,0,8,0

The defective part is the ":(1,11)=s4;,0,32;" field.  This is an unnamed opaque structure which corresponds to "struct A".  The stab already says that B has a public base class of A, so the unnamed opaque structure is unwanted.

I binary searched this back to the date range 2002-09-29 to 2002-10-01.  The culprit appears to be this patch from Mark Mitchell:

  http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01814.html

Specifically, there is a change in cp/class.c build_base_field.

build_base_field constructs a 'decl' for the base class and calls layout_nonempty_base_or_field to place the base class at an offset.  So far, so good.

Mark's patch adds some new code:

  ! /* Add the new FIELD_DECL to the list of fields for T.  */
  ! TREE_CHAIN (decl) = *next_field;
  ! *next_field = decl;
  ! next_field = &TREE_CHAIN (decl);

This new code causes the decl to appear in the stabs+ debug output as an unnamed structure at the appropriate offset and size.  gdb does not want this structure.

>How-To-Repeat:

>Fix:
I am not a gcc hacker, so I could be going about this completely the wrong way.  But I think this is a 1-line fix in build_base_field.  I am testing this patch now:

Index: class.c
==============
RCS file: /cvsroot/gcc/gcc/gcc/cp/class.c,v
retrieving revision 1.518
diff -u -r1.518 class.c
--- class.c     30 Jan 2003 16:02:54 -0000    1.518
+++ class.c     16 Feb 2003 17:36:16 -0000
@@ 3958,6 +3958,7 @@
      DECL_SIZE_UNIT (decl) = CLASSTYPE_SIZE_UNIT (basetype);
      DECL_ALIGN (decl) = CLASSTYPE_ALIGN (basetype);
      DECL_USER_ALIGN (decl) = CLASSTYPE_USER_ALIGN (basetype);
+     DECL_IGNORED_P (decl) = 1;

      /* Try to place the field.  It may take more than one try if we
        have a hard time placing the field without putting two
>Release-Note:
>Audit-Trail:
>Unformatted: