Re: killing gcc2_compiled., revised

[Daniel Berlin <dan at cgsoftware dot com>]

"Zack Weinberg" <zackw@stanford.edu> writes:

> This is a revised patch to eliminate ASM_IDENTIFY_GCC,
> ASM_IDENTIFY_LANGUAGE, i386afe.h, etc.  There are two changes from the
> previous patch.  dbxout.c now unconditionally emits a
> 
> 	.stabs "gcc2_compiled.",60,0,0,0
> 
> right after the N_SO stab; this is the recommended replacement for the
> gcc2_compiled. symbol.  (Decimal 60 is N_OPT.)  Target header files
> can override the string; m68k-motorola-sysv needs this (as determined
> by examining gdb's configuration fragments).  Other debug formats have
> other ways to identify GCC, e.g. DW_AT_producer.
> 
> John Marshall pointed out that labelling object files with GCC's
> version number is useful when doing archaeology, so I put this back.
> Now it's done by toplev.c if IDENT_ASM_OP is defined; this means we
> can still eliminate i386afe.h etc.  Hopefully, the space wastage will
> be addressed in binutils; I saw patches go by to merge identical
> strings.
> 
> I bootstrapped this on i686-linux with no apparent GCC regressions,
> then I built CVS GDB with the new compiler and ran its testsuite.
> This is the complete list of unexpected events.  I had to disable the
> threads tests otherwise expect got thoroughly wedged.

> I suspect the C++ failures are most or all due to gdb (or its
> testsuite) expecting the old mangler.

No, they are due to the fact that v3 abi support, while basically
done, hasn't been committed yet.

The others, however, worry me somewhat.
Do you have results from *before*?

>  The gdbtk tests blow up because
> I don't have that checked out.
> 
> zw