This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: dbxout.c stabs output problem


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]