New stabs with gcc HEAD

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

[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