This is the mail archive of the
mailing list for the GCC project.
New stabs with gcc HEAD
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gcc at sources dot redhat dot com
- Date: Tue, 26 Aug 2003 06:03:19 -0400
- Subject: New stabs with gcc HEAD
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)
int main ()
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:
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:
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
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?