gcc HEAD, stabs+, TYPE_CODE_INT problem

Michael Elizabeth Chastain
2004-04-05T19:09:51Z

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 this code is *not* legal stabs, then I can make a small test case
and then file a gcc PR. I already isolated the gcc patch which
causes this. It's a big C-declaration rewrite.

Michael C