Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

[Daniel Jacobowitz <drow@false.org>]

On Mon, Apr 05, 2004 at 03:09:42PM -0400, Michael Chastain wrote:
> My last test run got stabbed really badly by a new problem
> with gcc HEAD -gstabs+.  There are about 700 new non-PASS results.
> 
> The symptoms are: look at a global variable of type "char *".
> 
>   # gcc 3.3.3
>   (gdb) ptype s
>   type = char *
> 
>   # gcc HEAD 2004-03-30
>   (gdb) ptype s
>   type = <invalid type code 7> *
> 
> "invalid type code 7" is TYPE_CODE_INT.
> 
> With gcc 3.3.3, the stabs look like this:
> 
>   # gcc 3.3.3
>   .stabs	"char:t(0,2)=r(0,2);0;127;",128,0,0,0
>   .stabs	"__caddr_t:t(7,35)=(7,36)=*(0,2)",128,0,82,0
>   .stabs	"s:G(7,36)",32,0,7,0
> 
> With gcc HEAD, the stabs look like this:
> 
>   # gcc HEAD
>   .stabs	"__caddr_t:t(3,44)=(3,45)=*(3,46)=r(3,46);0;127;",128,0,82,0
>   .stabs	"s:G(3,45)",32,0,7,0
> 
> That is, gcc 3.3.3 emits a separate line for each primitive
> type such as "char".  gcc HEAD emits the definition of "char"
> as a nested definition inside the first type that uses char,
> such as pointer-to-char.
> 
> The big question is: is this legal stabs?  After reading
> stabs.texinfo, I'm inclined to think that it is.
> 
> If it's legal stabs, then someone has to enhance the stab reader.  I
> haven't started debugging gdb yet but I suspect that bit of code is
> getting confused by the new-style nested definition.  There's a bit of
> code in read_range_type to recognize the special case of "char" as 0 to
> 127, and gdb is behaving like that special-case isn't getting
> recognized.

If you debug further, I think you'll find that it is being recognized. 
The problem is probably that the type does not have a name; we're not
emitting any debug information that associates the name 'char' with
anything.

Zack, any idea?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer