Re: gnu ld problem with sparc solaris 2.8 assembler

[Nick Clifton]

Hi Ted,

: And while we're at it, what do you think of that warning in the gcc 
: notes (which i quoted in the mail i sent you?)

Well I would guess that it is probably out of date, but I am not an
expert on gcc's Solaris support, so I cannot say for sure.

: I don't see relocation information in the objdump output.
: I used all the flags that could possibly seem reasonable:
: objdump -dr --full-contents --disassemble --source --line-numbers --reloc 
--syms foo.o 

My fault, I should have said use '-Dr' not '-dr' (or --disassemble-all
- --reloc).  If you do that on the two foo.c.o files that you included
you get:

  % objdump -Dr foo.good.o

  foo.c.o:     file format elf32-sparc

  Disassembly of section .data:

  00000000 <Value>:
     0:   00 00 00 00     unimp  0
                          0: R_SPARC_32   FooBar

  % objdump -Dr foo.bad.o

  foo.c.o.2:     file format elf32-sparc

  Disassembly of section .data:

  00000000 <Value>:
     0:   00 00 00 00     unimp  0
                          0: R_SPARC_UA32 FooBar

(I have edited the output slightly to remove the display of the
contents of the .text section.  I have also guessed at the names of
the object files, since the metamail that you sent had two files
called foo.c.o.  I assumed that the first one was actually meant to be
foo.good.o and that the second one was meant to be foo.bad.o)

Anyway, the problem here is obvious.  One assembler is producing a
R_SPARC_UA32 reloc to initialise Value and the other is producing a
R_SPARC_32 reloc.  So it would seem that the GNU linker is not
handling the R_SPARC_UA32 reloc correctly.

These relocs are generated as a result of the input to the assembler
which looks like this: 

  Value:
        .uaword FooBar

Which is intended to allocate an unaligned word value.

There is code in the current GNU linker sources which is supposed to
handle the R_SPARC_UA32 reloc, so maybe it is a case that you are
using an older version of the linker.  You say that the problem is
still present if you use the 2.10 sources ?  One thing that I did see
in the current sources is this (in bfd/elf32-sparc.c):

static CONST struct elf_reloc_map sparc_reloc_map[] =
{
  { BFD_RELOC_NONE, R_SPARC_NONE, },
  ...
  { BFD_RELOC_SPARC_WDISP22, R_SPARC_WDISP22 },
  /* ??? Doesn't dwarf use this?  */
/*{ BFD_RELOC_SPARC_UA32, R_SPARC_UA32 }, not used?? */
  {BFD_RELOC_SPARC_10, R_SPARC_10},
  ....
};

It would appear that no-one thought that the UA32 reloc would be used.
If you try uncommenting this line and then rebuilding the linker, does
this solve the problem ?

Cheers
        Nick