Re: New stabs with gcc HEAD

[Daniel Jacobowitz <drow@mvista.com>]

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