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

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

[Dana, Eric]

When building some of our 64-bit libraries in C++, we are seeing
R_SPARC_DISP32 errors:

../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37:
    relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKc
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37: 
    relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass6indentEi
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(agentConditi
on.o):itimerspec/agentCondition.C:50:
    relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKcm
and many, many more...

This happens on Solaris 2.7/2.8 when linking  64-bit objects.
Below is a reference from another developer (taken from the binutils
archives)

   2002-05/msg01920.html   

At this time we have no workaround. Can a previous version of binutils be
used on Solaris with 64-bit linking
with GCC 3.1 or later?

--Eric Dana--
BMC Software Inc.

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[Alan Modra]

On Mon, Jul 15, 2002 at 12:45:33PM -0500, Dana, Eric wrote:
> When building some of our 64-bit libraries in C++, we are seeing
> R_SPARC_DISP32 errors:

Please try current binutils CVS.  If the problem isn't fixed there,
now would be the time to shout about it.  We're about to release 2.13.

http://sources.redhat.com/binutils/ for instructions on accessing the
cvs server.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[David S. Miller]

   From: Alan Modra <amodra@bigpond.net.au>
   Date: Tue, 16 Jul 2002 12:10:12 +0930

   On Mon, Jul 15, 2002 at 12:45:33PM -0500, Dana, Eric wrote:
   > When building some of our 64-bit libraries in C++, we are seeing
   > R_SPARC_DISP32 errors:
   
   Please try current binutils CVS.  If the problem isn't fixed there,
   now would be the time to shout about it.  We're about to release 2.13.

Actually this looks like some kind of code-model error.
There should not be any R_SPARC_DISP32 relocations generated
as no "call" instruction based function invocations should
be emitted with Solaris's default code model.

"Call" is the only way R_SPARC_DISP32 relocations can be
emitted.

I really doubt this is a binutils bug.  It is either some user
configuration error, or the libtool machinery is causing the
wrong code model to be used when generating the c++ libraries
and/or binaries.

If these folks are specifying the code-model explicitly on the
command line, and linking with libstdc++ this could cause errors
like the above as well.

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[Teemu Torma]

David S. Miller wrote:
>    From: Alan Modra <amodra@bigpond.net.au>
>    Date: Tue, 16 Jul 2002 12:10:12 +0930
> 
>    On Mon, Jul 15, 2002 at 12:45:33PM -0500, Dana, Eric wrote:
>    > When building some of our 64-bit libraries in C++, we are seeing
>    > R_SPARC_DISP32 errors:
> 
>    Please try current binutils CVS.  If the problem isn't fixed there,
>    now would be the time to shout about it.  We're about to release 2.13.

I have exactly the same problem with C++ code and gcc 3.1 and newer, and 
binutils 2.12.1 and newer.  

> Actually this looks like some kind of code-model error.
> There should not be any R_SPARC_DISP32 relocations generated
> as no "call" instruction based function invocations should
> be emitted with Solaris's default code model.
> 
> "Call" is the only way R_SPARC_DISP32 relocations can be
> emitted.

As far as I can see, only "call" instructions are ever emitted by gcc. 
Nothing changes if I use -m32, -m64, -mcmodel=<any value>.

Am I missing something, or am I just ignorant?

> I really doubt this is a binutils bug.  It is either some user
> configuration error, or the libtool machinery is causing the
> wrong code model to be used when generating the c++ libraries
> and/or binaries.
> 
> If these folks are specifying the code-model explicitly on the
> command line, and linking with libstdc++ this could cause errors
> like the above as well.

In my projects no libtool used, just plain makefiles.  No code models ever 
specified, just -m64.  And everything with plain C works, the only problem 
is with non-trivial C++, where shared libraries are built and used.  I 
don't really know what is the point when the problem appears, every time I 
try to produce a test case, it works.

Teemu

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[Alan Modra]

On Wed, Jul 17, 2002 at 07:06:50PM +0200, Teemu Torma wrote:
> David S. Miller wrote:
> >    From: Alan Modra <amodra@bigpond.net.au>
> >    Date: Tue, 16 Jul 2002 12:10:12 +0930
> > 
> >    On Mon, Jul 15, 2002 at 12:45:33PM -0500, Dana, Eric wrote:
> >    > When building some of our 64-bit libraries in C++, we are seeing
> >    > R_SPARC_DISP32 errors:
> > 
> >    Please try current binutils CVS.  If the problem isn't fixed there,
> >    now would be the time to shout about it.  We're about to release 2.13.
> 
> I have exactly the same problem with C++ code and gcc 3.1 and newer, and 
> binutils 2.12.1 and newer.  
> 
> > "Call" is the only way R_SPARC_DISP32 relocations can be
> > emitted.

David, are you sure you don't get these reloc types in dwarf2 debug
sections?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[David S. Miller]

   From: Alan Modra <amodra@bigpond.net.au>
   Date: Thu, 18 Jul 2002 10:43:51 +0930

   On Wed, Jul 17, 2002 at 07:06:50PM +0200, Teemu Torma wrote:
   > > "Call" is the only way R_SPARC_DISP32 relocations can be
   > > emitted.
   
   David, are you sure you don't get these reloc types in dwarf2 debug
   sections?

32-bit PC-relative relocations?  I really doubt it :-)

I did make a brain fart though, "call" is valid in several situations,
PIC function calls in particular because that goes through the PLT
which will be near the code itself.

I still maintain that this isn't a binutils bug but rather some other
problem.

A repeatable testcase from the bug reporter posted here and in GNATS
would be highly appreciated so that something concrete can be done
about this problem.  Currently we are groveling over the bug because
not enough information is present.  A reproducable testcase would
eliminate this problem.

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[Teemu Torma]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

On Thursday 18 July 2002 03:21, David S. Miller wrote:

> I did make a brain fart though, "call" is valid in several situations,
> PIC function calls in particular because that goes through the PLT
> which will be near the code itself.

All the failing symbols are in gnu.linkonce sections.  What happens when 
symbols get deleted.

> A repeatable testcase from the bug reporter posted here and in GNATS
> would be highly appreciated so that something concrete can be done
> about this problem.  Currently we are groveling over the bug because
> not enough information is present.  A reproducable testcase would
> eliminate this problem.

I finally managed to create test case that fails.  See the attached perl 
script that creates files, libraries and tries to link them in the current 
directory.

The script is slightly complex, since I had trouble reproducing it, and I 
thought it must be number or size of the libraries.  But it turns out that it 
starts failing only when there is more than one object in the "main" program.

$ perl link-test.pl
g++ -m64 -mcpu=ultrasparc -fPIC -c l_1_1.cc
g++ -m64 -mcpu=ultrasparc -fPIC -c l_1_2.cc
g++ -m64 -mcpu=ultrasparc --shared -o libl_1.so l_1_1.o l_1_2.o -L`pwd` 
g++ -m64 -mcpu=ultrasparc -c main_1.cc
g++ -m64 -mcpu=ultrasparc -c main_2.cc
g++ -m64 -mcpu=ultrasparc -o link-test main_1.o main_2.o -L`pwd` -ll_1
main_2.o(.eh_frame+0x70): relocation truncated to fit: R_SPARC_DISP32 
.gnu.linkonce.t._ZN7foo_1_1D1Ev
main_2.o(.eh_frame+0x90): relocation truncated to fit: R_SPARC_DISP32 
.gnu.linkonce.t._ZN7foo_1_110to_destroyC1Ev
main_2.o(.eh_frame+0xb0): relocation truncated to fit: R_SPARC_DISP32 
.gnu.linkonce.t._ZN7foo_1_110to_destroyD1Ev
main_2.o(.eh_frame+0xd0): relocation truncated to fit: R_SPARC_DISP32 
.gnu.linkonce.t._ZN7foo_1_18method_1Ev
main_2.o(.eh_frame+0xf0): relocation truncated to fit: R_SPARC_DISP32 
.gnu.linkonce.t._ZN7foo_1_18method_2Ev
main_2.o(.eh_frame+0x110): relocation truncated to fit: R_SPARC_DISP32 
.gnu.linkonce.t._ZN7foo_1_1C1Ev
collect2: ld returned 1 exit status

Teemu

[-- Attachment #2: link-test.pl --]
[-- Type: text/x-perl, Size: 3261 bytes --]

#!/usr/bin/env perl

$num_libs = 1;
$num_classes = 2;
$num_methods = 2;
$num_mains = 2;

$gxx = "g++ -m64 -mcpu=ultrasparc";

# Build method declarations.
my $method_decl, @method_decl;
my $method_call, @method_call;

foreach $method (1 .. $num_methods) {
    push (@method_decl, "void method_${method} () { throw 1; }");
    push (@method_call, "to_destroy d_${method}; method_${method} ();");
}
$method_decl = join ("\n  ", @method_decl);
$method_call = join ("\n    ", @method_call);

foreach $lib (1 .. $num_libs) {
    my @objs;
    
    foreach $class (1 .. $num_classes) {
	my $header = "l_${lib}_${class}.h";
	open (HEADER, ">${header}") || die "Can not open $header";
	print HEADER <<EOH;

#include <iostream>
#include <string>

struct foo_${lib}_${class} 
{
  typedef foo_${lib}_${class} self_type;

  struct to_destroy
  {
      to_destroy () { self_type tem; tem.method_1 (); }
      ~to_destroy () { self_type tem; tem.method_1 (); }
  };

  foo_${lib}_${class} ()
  {
    $method_call
  }
  foo_${lib}_${class} (const self_type &)
  {
    $method_call
  }
  ~foo_${lib}_${class} ()
  {
    $method_call
  }

  $method_decl

  static self_type bar ();

  std::string _a_string;
};
EOH
	close (HEADER);
    }
    foreach $class (1 .. $num_classes) {
	my $source = "l_${lib}_${class}.cc";
	my $object = "l_${lib}_${class}.o";

        open (SOURCE, ">${source}") || die "Can not open $source";
        foreach $j (1 .. $lib) {
	    foreach $i (1 .. $num_classes) {
		print SOURCE <<EOS1;
#include "l_${j}_${i}.h"
EOS1
	    }
	}

        print SOURCE <<EOS2;
foo_${lib}_${class}
foo_${lib}_${class}::bar ()
{
  std::cout << "something to instanciate templates\\n";
EOS2

        foreach $j (1 .. $lib) {
	    foreach $i (1 .. $num_classes) {
		print SOURCE <<EOS3;
  foo_${j}_${i}::bar ();
EOS3
	    }
        }

        print SOURCE <<EOS4;
  return foo_${lib}_${class} ();
}
EOS4

      close SOURCE;

      my $compile = "${gxx} -fPIC -c $source";
      print $compile, "\n";
      system ($compile) && die "Compilation failed";

      push (@objs, $object);
    }

  my $link
    = "${gxx} --shared -o libl_${lib}.so "
    . join (' ', @objs)
    . " -L`pwd` "
    . join (' ', @libs);
  print $link, "\n";
  system ($link) && die "Link failed";

  push (@libs, "-ll_${lib}");
}

foreach $main (1 .. $num_mains) {
    my $source = "main_${main}.cc";
    my $object = "main_${main}.o";

    open (MAIN, ">${source}") || die "Can not open ${source}";

    foreach $lib (1 .. $num_libs) {
        foreach $class (1 .. $num_classes) {
	    print MAIN <<EOM1;
#include "l_${lib}_${class}.h"
EOM1
	}
    }

    my $main_name = ($main == 1 ? "main" : "main_${main}");

    print MAIN <<EOM2;
int
${main_name} ()
{
EOM2

    foreach $lib (1 .. $num_libs) {
	foreach $class (1 .. $num_classes) {
	    next if ($class % 2 == 0);

	    print MAIN <<EOM3;
  foo_${lib}_${class}::bar ();
EOM3
	}
    }

    print MAIN <<EOM4;
  return 0;
}
EOM4

    close MAIN;

    my $compile = "${gxx} -c $source";
    print $compile, "\n";
    system ($compile) && die "Compilation failed";

    push (@mains, $object);
}

my $link = "${gxx} -o link-test "
 . join (' ', @mains)
 . " -L`pwd` " . join (' ', @libs);

print $link, "\n";
system ($link) && die "Link failed";

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[Jakub Jelinek]

On Mon, Jul 15, 2002 at 07:44:14PM -0700, David S. Miller wrote:
>    From: Alan Modra <amodra@bigpond.net.au>
>    Date: Tue, 16 Jul 2002 12:10:12 +0930
> 
>    On Mon, Jul 15, 2002 at 12:45:33PM -0500, Dana, Eric wrote:
>    > When building some of our 64-bit libraries in C++, we are seeing
>    > R_SPARC_DISP32 errors:
>    
>    Please try current binutils CVS.  If the problem isn't fixed there,
>    now would be the time to shout about it.  We're about to release 2.13.
> 
> Actually this looks like some kind of code-model error.
> There should not be any R_SPARC_DISP32 relocations generated
> as no "call" instruction based function invocations should
> be emitted with Solaris's default code model.
> 
> "Call" is the only way R_SPARC_DISP32 relocations can be
> emitted.

No, call generates R_SPARC_WDISP32. R_SPARC_DISP32 is generated by
something like .word %r_disp32(foo + 12345).

%r_disp32() is emitted by gcc for the .eh_frame section (only when using
GNU ld, since Solaris ld has broken support for misaligned PC relative
relocs).
Are your 64-bit libraries bigger than 2GB?

	Jakub

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

[Dana, Eric]

When building some of our 64-bit libraries in C++, we are seeing
R_SPARC_DISP32 errors:

../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37:
    relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKc
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37: 
    relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass6indentEi
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(agentConditi
on.o):itimerspec/agentCondition.C:50:
    relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKcm
and many, many more...

This happens on Solaris 2.7/2.8 when linking  64-bit objects.
Below is a reference from another developer (taken from the binutils
archives)

   2002-05/msg01920.html   

At this time we have no workaround. Can a previous version of binutils be
used on Solaris with 64-bit linking
with GCC 3.1 or later?

--Eric Dana--
BMC Software Inc.

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

[Brad Spencer]

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

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[Daniel Jacobowitz]

On Tue, May 28, 2002 at 11:49:49AM -0300, Brad Spencer wrote:
> 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

Could you try this with a 2.13 snapshot?  There's one in
/pub/binutils/snapshots, marked 2.12.91.

> 
> 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

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors

[Brad Spencer]

On Mon, Jul 29, 2002 at 11:34:23PM -0400, Daniel Jacobowitz wrote:
> On Tue, May 28, 2002 at 11:49:49AM -0300, Brad Spencer wrote:
> > 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
> 
> Could you try this with a 2.13 snapshot?  There's one in
> /pub/binutils/snapshots, marked 2.12.91.

I will try this today and report back.  It's my understanding I'll
need >=2.12 for gcc-3.2, so this was a pleasant surprise :)

> > 
> > 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
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
-----------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
  Systems Architect | InfoInterActive Corp. | An AOL Company