Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

Daniel Jacobowitz
2004-04-05T19:32:09Z

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