This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]