gcc 3.0.3 + binutils 2.11.2 problems on sparc-sun-solaris2.6

[Colin Howell <chowell at redhat dot com>]

When I built gcc 3.0.3 using binutils 2.11.2 on a sparc-sun-solaris2.6
system, with gcc configured to use the binutils assembler and linker
(instead of the normal case, where it uses the Solaris assembler and
linker), I found the resulting compiler had a very large number of
execute failures in the g++, objc, libstdc++, and libjava testsuites.

To make a long story short, the problem turns out to be a known bug
(Sun BugID 4210064) in the Solaris 2.6 ld.so.  Sometimes it will
corrupt R_SPARC_UA32 relocations in shared libraries, only copying the
lowest 3 bytes of the relocated address.  This may cause the shared
library to segfault or experience other problems.

(See http://gcc.gnu.org/ml/gcc-bugs/1999-03/msg00386.html)

Because of this, even trivial C++ programs built by my gcc 3.0.3
compiler would segfault on exit, since the exit cleanup code in
libstdc++.so tried to access a corrupted relocation.

I do not know if Sun has ever provided a fix for this bug for Solaris
2.6.  Nor do I have the ability to patch any Solaris machine that I
have access to.

The reason that gcc 3.0.3 together with binutils 2.11.2 trigger this
problem is that gcc now uses the .uaword directive for any 4-byte data
object, regardless of its alignment, due to the following code in
gcc/config/sparc/sol2.h:

/* Use .uahalf/.uaword so packed structure members don't generate
   assembler errors when using the native assembler.  */
#undef ASM_SHORT
#define ASM_SHORT ".uahalf"
#undef ASM_LONG
#define ASM_LONG ".uaword"

This code is rather old (it predates the EGCS project at the very
least), and it has only recently been removed from the mainline.

binutils 2.11.2, when it sees all these .uaword directives, dutifully
converts them into R_SPARC_UA32 relocations, again without checking
whether an unaligned relocation is really necessary.  (See
md_pseudo_table[], s_uacons(), and cons_fix_new_sparc() in
gas/config/tc-sparc.c.)

So, as a result, the shared libraries generated have far more
R_SPARC_UA32 relocations than they need, and the chance of ld.so
corrupting a relocation is greatly increased.

I suspect that other Solaris versions may also be affected by this
problem, but I have not had the opportunity to test them yet.
However, from some old test results from Alexandre Oliva:

http://gcc.gnu.org/ml/gcc-testresults/2001-08/msg00531.html
http://gcc.gnu.org/ml/gcc-testresults/2001-08/msg00532.html
http://gcc.gnu.org/ml/gcc-testresults/2001-08/msg00533.html

it looks like Solaris versions 2.5, 2.6, and 2.7 may all be affected.
(Yes, these results are for an older gcc prerelease, but the pattern
looks suspiciously similar to what I saw.)

Is there any way to work around this problem, or at least warn Solaris
2.6 users not to configure gcc 3.0.4 to use binutils 2.11.2, before
gcc 3.0.4 goes out?