Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

[Michael Elizabeth Chastain]

Zack Weinberg writes:

> Not emitting them was unintentional, and I imagine getting them back
> would be straightforward. ...  Would you please file a bug report
> against GCC, and assign it to me?  And any further investigation you
> could do would be greatly appreciated.

Cool.  I've got a bug report all set to file, except that it looks
like the httpd on gcc.gnu.org just crashed!  :-(  You'll have it soon.

The bug does not happen with gcc gcc-3_4-branch so I agree it is
lesser priority than any 3.4 activity.

BTW, dwarf-2 is okay.  I saw no regressions with gdb 6.0,
gdb test suite 6.0, gcc HEAD, and dwarf-2.

Michael C

Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

[Zack Weinberg]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:

> BTW, dwarf-2 is okay.  I saw no regressions with gdb 6.0,
> gdb test suite 6.0, gcc HEAD, and dwarf-2.

Good to know, thanks.

zw

Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

[Zack Weinberg]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:
[...]
> gcc 3.3.3 (and gcc HEAD 20040323) emitted about 20 stab lines for the
> list from first_builtin_decl to last_builtin_decl.  This provides gdb
> with names for "char", "int", "float", et cetera.  gcc HEAD 20040330 no
> longer uses provides this list so there are no more stab lines for the
> builtin types.  Can we change gcc to bring these builtins back?

Not emitting them was unintentional, and I imagine getting them back
would be straightforward.  However, I don't know a lot about dbxout.c
and right now I have things to do for the 3.4.0 release (which doesn't
include these patches) that take priority - so I'm not likely to try
to fix this this week.

Would you please file a bug report against GCC, and assign it to me?
And any further investigation you could do would be greatly appreciated.

zw

Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

[Michael Elizabeth Chastain]

Daniel's on the money, as usual.

With these stabs:

    # 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

gdb prints "(7,36)" as "(0,2) *" and prints "(0,2)" as "char" because
"char" is the name of the type, for an end result of "char *".  I can
see this happening by stepping through gdb.  Also, if I hand-edit the
first stab and change "char:t(0,2)=r(0,2)" to "foo_char:t(0,2)=r(0,2)",
then the name of the type changes.

With these stabs:

    # 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

gdb prints "(3,45)" as "(3,46) *", but the type "(3,46)" has no name.

Zack, this happened with your c-decl rewrite.  I did the date-narrowing
process and isolated it to this patch.

gcc 3.3.3 (and gcc HEAD 20040323) emitted about 20 stab lines for the
list from first_builtin_decl to last_builtin_decl.  This provides gdb
with names for "char", "int", "float", et cetera.  gcc HEAD 20040330 no
longer uses provides this list so there are no more stab lines for the
builtin types.  Can we change gcc to bring these builtins back?

Either that, or we have to change gdb to recognize the unnamed ranges
and interpolate names for them, which gets icky real fast for a
cross-debugger.

Michael C

Re: gcc HEAD, stabs+, TYPE_CODE_INT problem

[Daniel Jacobowitz]

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

gcc HEAD, stabs+, TYPE_CODE_INT problem

[Michael Elizabeth Chastain]

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