New stabs with gcc HEAD

New stabs with gcc HEAD

[Michael Elizabeth Chastain]

[Argh!  I sent this to gcc@sources.redhat.com because I was thinking of gcc.
 But I really want to talk about the issue with gdb people first!]

gcc HEAD changed its stabs and gdb is choking on the new stabs.
This happens with C++ and type "char *".

The test case is pretty simple:

  char * dm_type_char_star (char *p)
  {
    return p;
  }

  int main ()
  {
    return 0;
  }

Compile this with "g++ -gstabs+" with an i386 target.
(It's important to use an i386 because the bug depends on
target-specific definition of __builtin_va_list).

The old good stabs look like this:

  .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 

There is a stab for "char" type.  Then the types that use "char *"
refer back to (0,2).

The new bad stabs look like this:

  .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

There is no more stab for the builtin type "char".  So
__builtin_va_list defines its own integral type as
(0,11) with no name, and then dm_type_char_star refers to it.

The lack of a name means gdb isn't going to print "char".
In fact, gdb 5.3 gets unhappy:

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

gdb HEAD behaves the same way.

Over in gcc land, I found the critical patch, so it ought to
be easy for gcc to revert their behavior if we ask them to.
(In fact I even patched my own compiler but the patch is probably
bogus).

So my question is: should we enhance gdb to handle these stabs?
It would be painful, because there is no type name, so we would
have to infer from the "0;127" range that this is a "char".
Or should we push back on gcc to emit an explicit stab for
the "char" type?

Michael C

Re: New stabs with gcc HEAD

[Daniel Jacobowitz]

On Tue, Aug 26, 2003 at 06:12:35AM -0400, Michael Elizabeth Chastain wrote:
> [Argh!  I sent this to gcc@sources.redhat.com because I was thinking of gcc.
>  But I really want to talk about the issue with gdb people first!]
> 
> gcc HEAD changed its stabs and gdb is choking on the new stabs.
> This happens with C++ and type "char *".
> 
> The test case is pretty simple:
> 
>   char * dm_type_char_star (char *p)
>   {
>     return p;
>   }
> 
>   int main ()
>   {
>     return 0;
>   }
> 
> Compile this with "g++ -gstabs+" with an i386 target.
> (It's important to use an i386 because the bug depends on
> target-specific definition of __builtin_va_list).
> 
> The old good stabs look like this:
> 
>   .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 
> 
> There is a stab for "char" type.  Then the types that use "char *"
> refer back to (0,2).
> 
> The new bad stabs look like this:
> 
>   .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
> 
> There is no more stab for the builtin type "char".  So
> __builtin_va_list defines its own integral type as
> (0,11) with no name, and then dm_type_char_star refers to it.
> 
> The lack of a name means gdb isn't going to print "char".
> In fact, gdb 5.3 gets unhappy:
> 
>   (gdb) print &'dm_type_char_star(char*)'
>   $1 = (<invalid type code 7> *(*)(
>       <invalid type code 7> *)) 0x80482f4 <dm_type_char_star(char*)>
> 
> gdb HEAD behaves the same way.
> 
> Over in gcc land, I found the critical patch, so it ought to
> be easy for gcc to revert their behavior if we ask them to.
> (In fact I even patched my own compiler but the patch is probably
> bogus).
> 
> So my question is: should we enhance gdb to handle these stabs?
> It would be painful, because there is no type name, so we would
> have to infer from the "0;127" range that this is a "char".
> Or should we push back on gcc to emit an explicit stab for
> the "char" type?

I'd say GCC was broken.  What patch broke it?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New stabs with gcc HEAD

[Michael Elizabeth Chastain]

Okay, I filed a gcc PR.

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12066

This bumped up the non-PASS count for gdb 5.3 from 350 to 427.

Michael C

Re: New stabs with gcc HEAD

[Michael Elizabeth Chastain]

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.