dbxout.c stabs output problem

[Jim Wilson]

	1) Are the "new" stabs correct or a bug?

They are apparently buggy, but it is not clear why yet.

	2) If new, what are the rules/syntax now?

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.

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.

	 It now expects "ar0" and
	will read past the second "=" (it was dying with "unexpected symbol at
	end of stabs: =").

I believe the ar0 is a bug.

	 So far it appears to working fine, with the only
	side-effect being a slew of warnings about e.g. "undefined type 110",
	with the number always the middle forward reference in, e.g.
	"t109=110=*2" coming from gcc's dbxout.c.

Nested definitions like this are valid.  The extra number appears to be
always unnecessary in this case though.

	 If I'm not mistaken, forward
	references with 2.7 are all prefixed by 'x' (and stabshll.c was written
	to expect those).

These are called cross-reference stabs.  The code to emit them is still in gcc.
They are only supported for forward references to structure/union types though,
because you can refer to such a type before it has been completely defined.
We shouldn't need them for pointer types.

	PBAR:t6=7=*2;

	But in that case,
	doesn't the second number assigned to PBAR in my example become
	unnecessary? PBAR is clearly type 6 or pointer to 2, and marked as
	different by its type number, so there's no more need for the old
	differentiating increment (new type number 7) which now ends up
	resembling a forward reference.

You never told me what PBAR/PCHAR is.  Is it tough to debug a problem when
I don't have access to any testcase.  But just trying a few things, I think
you have something like this:

typedef char CHAR;
typedef char * PCHAR;

I am able to reproduce the problem with this testcase.

	Looking at it from another angle, if we describe
	... long explanation..
	Does that make sense?

That is a good description of the effect, but we really need to investigate
the cause of the problem.  I tracked it down to this change:

	Mon Feb 12 14:43:50 1996  Per Bothner  <bothner@cygnus.com>

        Changes to distinguish typedef from original type in debug output.
        * tree.h (DECL_ORIGINAL_TYPE):  New macro.
        * tree.c (copy_node):  Zero out type.symtab union.
        * c-decl.c (pushdecl):  Set DECL_ORIGINAL_TYPE for typedef origin.
        * dbxout,c (dbxout_type):  Don't canonicalize typedef type to base.

So it was roughly the same batch of changes that caused this problem as
caused the other problem you found.

I suspect the problem here is that the dbxout.c change is adding an
unnecessary recursize call inside dbxout_type, which is giving us the
unnecessary nested type definitions.  However, I am unsure if this is
completely unnecessary.

	The new C++ stabs kill emxomf completely.

C++ stabs have always been a mess.  However, there have been very few changes
to dbxout.c, so most of the changes you are seeing are probably due to C/C++
front end changes.

I think there is only one major change to dbxout.c since gcc-2.7, and
that is the support for Sun-style BINCL stabs.  This adds a file index to
stabs, and surrounds them with BINCL (begin include) and EINCL (end include)
stabs.  This allow us to delete duplicate groups of stabs, e.g. if you have a
header file that is included in two source files, you get two copies of the
debug info, and the linker can delete one copy as redundant.

Jim