dbxout.c stabs output problem

[Jim Wilson]

Note that this isn't really a gcc vs egcs problem, as egcs is emitting the
same stabs as gcc 2.8.

	I've been doing a bit of work on getting rid of the bug that was causing
	the OS/2 port of pgcc (pgcc-2.90.27 980315, egcs-1.0.2 release) to fail
	when -g or -gstabs was combined with -Zomf, an emx+gcc switch for
	creating OMF files.

What exactly is failing?  The linker?  Is this something we might be able to
fix, such as GNU ld?  Or is this someone else's program that we can't fix?

	1) Arrays show up as ar0 instead of ar1.
	...and `0' is an undefined type...

This was broken by this change.

Tue Feb  6 17:22:29 1996  Per Bothner  <bothner@cygnus.com>

	* dbxout.c (dbxout_range_type):  Emit non-range INTEGER_TYPE
	as a sub-range of itself (so gdb can tell the difference).

There was a gdb change at the same time.

Tue Feb  6 21:37:03 1996  Per Bothner  <bothner@kalessin.cygnus.com>

	* stabsread.c (read_range_type):  If !self-subrange and language
	is Chill, assume a true range.  If a true_range is a sub_subrange,
	use builtin_type_int for index_type.

This was an attempt to get better debug info for Chill, but it unfortunately
causes us to get incorrect debug info for C.  Hopefully, Per can give us
additional details about what the change was intended to do.

We might have to clarify how we represent range types in gcc.  The C front
end is just using an anonymous integer type for the array domain, and it isn't
safe to emit debug info based on that type.  The Ada front end always set
TREE_TYPE if this is a true range type.  I think the point of this patch is
to emit something different for types that are not true-range types, so that
we can tell the difference.  The way it is doing it though isn't very good, as
we really don't want references to undefined types, and we don't want to
define every anonymous integer type so we can subrange it.  Perhaps this
problem needs to be fixed in the Chill front end to eliminate the ambiguity
there.

	2) The second problem is also visible in the above snippet: the apparent
	forward references generated by egcs's dbxout.c.

	.stabs "CHAR:t50=2",128,0,192,0
	.stabs "PCHAR:t51=52=*50",128,0,193,0

The forward reference does look funny.  Can you give an example for this?
This is happening somewhere inside your stdio.h file, which I don't have.
Offhand, I am not sure if forward references are supposed to be invalid
though.

	With egcs, the t number is really more of a name index than a type
	number, as in both C and C++ typedefs do not create new types, but only
	synonyms.

It is true that the types are not distinct, but the names are distinct, and
it is names that are most useful to the user.  If the user writes
	size_t array[100];
then we want gdb to know that it is actually an array of size_t, and not an
array of whatever type size_t happens to be for this target.  In order to
do this, we must give a number to the size_t type.  So this is an intentional
change which gives better debug info.

	Interestingly enough, set up the same input file for .cpp compilation
	and egcs/pgcc produces:
	.stabs "CHAR:t2",128,0,192,0
	.stabs "PCHAR:t32",128,0,193,0
	which has none of the automatic index numbering and is effectively
	identical to the old gcc output.

I'd call this a bug in the C++ debug info.  There are some differerences
between a C typedef and a C++ typedef, which shows up in the internal
representation for them.  The code that emits stabs for typedefs is probably
getting confused by this.

Jim