New stabs with gcc HEAD

Michael Elizabeth Chastain
2003-08-26T10:12:36Z

[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