Re: ld broken on Solaris 8

[Jeff Sturm <jsturm at one-point dot com>]

Tod Thomas wrote:
> I just read this archived post:
> http://sources.redhat.com/ml/binutils/2000-04/msg00333.html
> Has the cause of this problem been determined? 

I'd like to know too.  I hack compilers, not linkers, but I thought I'd
give this one a shot.

On my Solaris 7 host I traced the failure down to a relocation in
crtbegin.o:

$ readelf -r crtbegin.o
...
Relocation section '.rela.data' at offset 0x590 contains 1 entries:
  Offset    Info  Type       Symbol's Value  Symbol's Name       Addend
  00000000  00c17 R_SPARC_UA32          00000000  __DTOR_LIST__     + 4

So this location should be initialized to __DTOR_LIST__ + 4.  It fails
with GNU ld -- gdb shows this address contains zero.  With a native ld, it
links and runs fine.

Luckily I have a working cross toolchain I can compare with:

Relocation section '.rela.data' at offset 0x944 contains 1 entries:
  Offset    Info  Type       Symbol's Value  Symbol's Name       Addend
  00000004  00703 R_SPARC_32            00000000  __DTOR_LIST__     + 4

hmm... now my questions:

1) What is the difference between R_SPARC_32 AND R_SPARC_UA32?

2) Does GNU ld understand R_SPARC_UA32 at all?

3) Why do the native and cross toolchains differ?

I think I can answer 3)... crtbegin.o must've been assembled by the native
as.  My workaround is to configure GCC using --with-as=<path to GNU as>
and --with-ld=<path to GNU ld>.  That worked for me, YMMV.

So unless my reasoning is flawed somewhere, a bug in GCC has triggered a
bug in binutils.  An option-less configure should choose either GNU or
native binutils (i.e. not both), and GNU ld should be able to link output
of the native Solaris assembler.

Jeff