This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld broken on Solaris 8
Date: Fri, 11 May 2001 09:03:10 -0700
From: "H . J . Lu" <hjl@lucon.org>
On Thu, May 10, 2001 at 11:43:41PM -0700, Jeff Sturm wrote:
>
> 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?
According to the Sun "Linker and Libraries Guide" R_SPARC_UA32
"...resembles R_SPARC_32, except that it refers to an unaligned
word. That is, the word to be relocated must be treated as four
separate bytes with arbitrary alignment, not as a word aligned
according to the architecture requirements."
Now that's a bit cryptic to me, but I suspect the Sparc doesn't allow
unaligned word access (or severely penalizes it) and R_SPARC_UA32 is
there to instruct the dynamic linker to access the bytes individually
instead of trying an unaligned word access. If I'm right, this would
probably mean that for ld there would be no difference.
> 2) Does GNU ld understand R_SPARC_UA32 at all?
Befere my patch (the one HJ pointed at) it certainly didn't do the
right thing for R_SPARC_UA32. With that patch, it worked for me. It
looks like the patch isn't present in the latest official binutils
release. Perhaps someone should move it over to the
binutils-2_11-branch. Jeff and/or Tod could try a recent snapshot to
see if it works.
This BFD patch may or may not have something to do with it.
2001-02-09 Mark Kettenis <kettenis@gnu.org>
* elf32-sparc.c (_bfd_sparc_elf_howto_table): Treat R_SPARC_UA32
similar to R_SPARC_32.
* elf64-sparc.c (sparc64_elf_howto_table): Likewise.
Sorry, I know nothing about Sparc.
H.J.