Re: New stabs with gcc HEAD

[Michael Elizabeth Chastain <mec@shout.net>]

Here, let me just blort out the README.txt from the bug report that
I'm going to file (if we agree that we think it's a gcc bug).

===

Problem with g++ stabs+ builtin types
Michael Elizabeth Chastain, <mec@shout.net>
2003-08-26

Synopsis

  g++ generates stabs for "char *" that gdb cannot read.

  The bad stabs are:
    .stabs  "__builtin_va_list:t(0,10)=*(0,11)=r(0,11);0;127;",128,0,0,0
    .stabs  "_Z17dm_type_char_starPc:F(0,13)=*(0,11)",36,0,2,_Z17dm_type_char_starPc

  The previous good stabs were:
    .stabs  "char:t(0,2)=r(0,2);0;127;",128,0,0,0
    .stabs  "__builtin_va_list:t(0,20)=*(0,2)",128,0,0,0
    .stabs  "_Z17dm_type_char_starPc:F(0,24)=*(0,2)",36,0,2,_Z17dm_type_char_starPc

  This happens because g++ no longer generates an explicit stabs
  record for "char", so the "char" gets defined with no name
  in the middle of its first use in __builtin_va_list.

Files

  README.txt	this file
  null.8207.s   g++ -gstabs+ -x c++ -S /dev/null
  null.8208.s   g++ -gstabs+ -x c++ -S /dev/null
  z1.cc         small test program
  z1.8207.s     g++ -gstabs+ -S z1.cc
  z1.8208.s     g++ -gstabs+ -S z1.cc
  z1.patch.s    g++ -gstabs+ -S z1.cc

  The "8207" files are with gcc version 2003-08-20 07:00:00 UTC.
  The "8208" files are with gcc version 2003-08-20 08:00:00 UTC.
  The z1.patch.s file is after applying my patch to gcc (see below).

Environment

  target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0
  gdb=5.3, gcc=2003-08-20 08:00:00 UTC, binutils=2.14, glibc=2.2.93-5-rh
  gformat=stabs+, glevel=2

How To Reproduce

  It's important to do this on with i386 target because the definition
  of __builtin_va_list is relevant.

  It's important to use -gstabs+.

  Compile and link z1.cc with g++ HEAD from 2003-08-20 08:00:00 UTC or later.
  binutils and glibc version do not matter.

  Run gdb 5.3 or later.

    (gdb) print &'dm_type_char_star(char*)'
    $1 = (<invalid type code 7> *(*)(
        <invalid type code 7> *)) 0x80482f4 <dm_type_char_star(char*)>

History Search

  This patch caused the change:

    2003-08-19  Mark Mitchell  <mark@codesourcery.com>

      ...
      PR c++/11036
      ...
      * decl.c ...
      (record_builtin_type): Do not call pushdecl.

  http://gcc.gnu.org/ml/gcc-patches/2003-08/msg001155.html

  I don't know the reason for this change.

Analysis

  gdb complains because it can't figure out the stabs for the
  return type of dm_type_char_star and the parameter type of
  dm_type_char_star.

  The bad stabs are:

    .stabs  "__builtin_va_list:t(0,10)=*(0,11)=r(0,11);0;127;",128,0,0,0
    .stabs  "_Z17dm_type_char_starPc:F(0,13)=*(0,11)",36,0,2,_Z17dm_type_char_starPc

  You can see the whole file in z1.8208.s.

  The problem is that many of the stabs for primitive types have gone
  away.  Compare z1.8207.s with z1.8208.s.  Even more clearly, compare
  null.8207.s with null.8208.s (types defined for an empty file).
  __builtin_va_list needs "char *", so the stab for __builtin_va_list
  defines a "char" type internally with no name.  Then my function
  dm_type_char_star ends up using the internal no-name type.  The
  no-name type confuses gdb.

  For reference, __builtin_va_list on the i386 is built here:

    /* config/i386/i386.c */
    tree
    ix86_build_va_list (void)
    {
      ...
      if (!TARGET_64BIT)
	return build_pointer_type (char_type_node);
    }
  
  If you look at c_common_nodes_and_builtins, it uses two different
  mechanisms to define types.  Some types are defined with
  record_builtin_type, and some of the types are defined with
  (*lang_hooks.decls.pushdecl (build_decl (...))).  Only the types
  defined with pushdecl wind up in the stabs output.

How To Fix

  I tried this and it worked for me:

    --- /berman/fsf/_today_/source/gcc/HEAD/gcc/gcc/c-common.c	2003-08-20 18:36:08.000000000 -0400
    +++ c-common.c	2003-08-26 04:52:29.000000000 -0400
    @@ -3019,8 +3019,12 @@
       tree va_list_arg_type_node;
     
       /* Define `int' and `char' first so that dbx will output them first.  */
    -  record_builtin_type (RID_INT, NULL, integer_type_node);
    -  record_builtin_type (RID_CHAR, "char", char_type_node);
    +  (*lang_hooks.decls.pushdecl) (build_decl (TYPE_DECL,
    +					    get_identifier ("int"),
    +					    integer_type_node));
    +  (*lang_hooks.decls.pushdecl) (build_decl (TYPE_DECL,
    +					    get_identifier ("char"),
    +					    char_type_node));
     
       /* `signed' is the same as `int'.  FIXME: the declarations of "signed",
	  "unsigned long", "long long unsigned" and "unsigned short" were in C++

  This makes 'int' and 'char' always appear as explicit
  distinct types in the debug output.  z1.patch.s is gcc output
  with this patch applied.

  I don't even know the difference between 'record_builtin_type'
  and 'pushdecl build_decl' so I expect that this patch is bogus.
  But that's the general idea.  'char' needs to be explicit so
  that __builtin_va_list does not define it implicitly.  There are
  probably quiet dependencies on explicit 'int' type as well.

  Alternatively, one could change something else to process the
  dependency of __builtin_va_list on 'char' so that an explicit
  'char' type gets emitted.  Anything that gets the 'char' type
  emitted is fine.