This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: dbxout.c stabs output problem
- To: Jim Wilson <wilson at cygnus dot com>
- Subject: Re: dbxout.c stabs output problem
- From: Henry Sobotka <sobotka at axess dot com>
- Date: Tue, 14 Jul 1998 14:27:50 -0700
- CC: law at cygnus dot com, egcs-bugs at cygnus dot com, bothner at cygnus dot com
- References: <199807132352.QAA00198@rtl.cygnus.com>
Jim Wilson wrote:
>
> There is stabs documentation in gdb/doc/stabs.texinfo. If gcc is emitting
> stabs that disagree with this, then it could be a gcc bug, or it could be
> that the documentation is out of date.
I compared the latest stabs.texinfo (gdb 4.17) earlier version I had
been using and the diffs are essentially new info about BINCL and EINCL.
Not a word about the difference I'm seeing in C++ stabs.
For example:
simpletest.cpp
-------------------------------------------
typedef struct {
long lo, hi;
} longlong;
int main(void)
{
return(0);
}
-------------------------------------------
Compiled with -g -S, gcc 2.7 produces the following stabs for longlong:
.stabs
"longlong:t20=s8lo:3,0,32;hi:3,32,32;$_0::21=##22=*20;:__3$_0;2A.23=##22;:__3$_0RC3$_0;2A.;__as::24=##25=&20;:3$_0RC3$_0;2A.;;",128,0,3,0
which can easily be parsed based on the info in the stabs manual. But
with ecgs/pgcc (gcc 2.8 stabs) we get:
.stabs
"longlong:t24=s8lo:3,0,32;hi:3,32,32;__as::25=#24,26=&24,27=*24,28=&29=s8lo:3,0,32;hi:3,32,32;__as::25:__as__3$_0RC3$_0;2A.;$_0::30=#24,27,27,28,20;:__3$_0RC3$_0;2A.31=#24,27,27,20;:__3$_0;2A.;;,20;:__as__3$_0RC3$_0;2A.;$_0::30:__3$_0RC3$_0;2A.31:__3$_0;2A.;;",128,0,3,0
Fed this stabs, emxomf breaks on the last 20 (in the ";;,20;:__as__"
sequence) with an "invalid type for member function __as" message. t20
here is the basic void type, i.e.
.stabs "void:t20=20",128,0,0,0
The front end is clearly doing a lot more with struct longlong than it
did before.
> In a practical sense, gcc stabs are considered correct if the gdb testsuite
> passes. Sometimes, gcc stabs are considered incorrect if other programs
> reading them (such as the SunOS4 dbx) fail.
I would put emxomf in that category and attribute its failures to either
new or buggy stabs, or a combination of the two as we saw with ar0 and
the possibly unnecessary nested type definitions. But whether its crash
on the "20" is a bug or new info that it has to be rewritten to expect
is very hard to tell amid the far more elaborate stabs.
Henry