Re: New stabs with gcc HEAD

Daniel Jacobowitz
2003-08-26T13:44:20Z

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