Using binutils-2.13 on sparc64-sun-solaris2.8 to build gcc-3.1.1 results in relocation errors

[Brad Spencer <spencer at infointeractive dot com>]

After having no success with gcc-3.1 and binutils-2.12.1 on
sparc64-sun-solaris2.8 (I used binutils-2.11.2 for this target), I've
tried again with binutils-2.13 and gcc-3.1.1.  I've encountered the
exact same problem when trying to link C++ programs.  If I swap out
binutils-2.13 with binutils-2.11.2 (under a gcc-3.1.1 built for
binutils-2.13) then linking works.

My latest efforts have included trying to disable HAVE_AS_SPARC_UA_PCREL
and HAVE_AS_SPARC_UA_PCREL_HIDDEN in gcc, but to no avail.
Considering I can merely swap out the binutils (and even link
libraries made with 2.13 and a 2.13-aware compiler), I suspect this is
a binutils bug.  I post in the hopes that someone can lend me some
insight.

My next step is to start looking at the diffs between 2.11.2 and
2.12.1 as far as bfd's relocation overflow detection goes.  Am I on
the right track?  BTW, my latest work has been with a cross compiler,
but it's no different than when using a native toolchain.

Previous post follows:

I've looked through the archives and the comments in gcc-3.1, and it
looks like this might be some sort of new feature that doesn't quite
work correctly.  If I configure gcc-3.1 on top of binutils-2.12.1,
then when I link 64-bit objects, I get things to the effect of

netra-map1:~$ g++ -Wall -m64 -o foo foo.cc -save-temps
/opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../../sparcv9/libstdc++.a(stl-inst.o)(.eh_frame+0xf0):
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZNSt24__default_alloc_templateILb1ELi0EE8allocateEm

This is totally a Hello World application:

static const char *st_ID __attribute__((unused)) =
"$Id$";

#include <iostream>

int
main()
{
  std::cout << "hello world" << std::endl;
  return 0;
}

When I configure gcc-3.1 on top of binutils-2.11.2, this doesn't
happen. 

netra-map1:~$ g++ -m64 -Wall -o foo foo.cc -save-temps
netra-map1:~$ ./foo
hello world

Inside gcc-3.1/gcc/config/sparc/sparc.h, I find the following
comment:

   /* [...]
   binutils 2.12 would emit a R_SPARC_DISP32 dynamic relocation if the
   symbol %r_disp32() is against was not local, but .hidden.  In that
   case, we have to use DW_EH_PE_absptr for pic personality.  */

>From what I can tell from this mailing list, the %r_dispX notation is
a new feature in gas.  Is this a bug?

netra-map1:~$ gcc -v
Reading specs from
/opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs
Configured with: ../gcc-3.1/configure --with-dwarf2
--enable-languages=c,c++ --enable-threads=single --disable-shared
--with-gnu-as --with-gnu-ld --with-as=/opt/bin/as
--with-ld=/opt/bin/ld --prefix=/opt/gcc-3.1
Thread model: single
gcc version 3.1
netra-map1:~$ gcc -print-prog-name=as
/opt/bin/as
netra-map1:~$ /opt/bin/as --version
GNU assembler 2.11.2
netra-map1:~$ gcc -print-prog-name=ld
/opt/bin/ld
netra-map1:~$ /opt/bin/ld --version
GNU ld 2.11.2
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf32_sparc
   elf64_sparc
        
-- 
-----------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
  Systems Architect | InfoInterActive Corp. | An AOL Company