Inconsistent R_SPARC_RELATIVE addend handling

[James Clarke <jrtc27 at jrtc27 dot com>]

Hi,
As discussed in [0] on the binutils mailing list, RELATIVE relocations on
sparc32 and sparc64 have unusual behaviour, and when this is forgotten, ld can
end up being made to emit bad objects.

On sparc32, elf_machine_rela and elf_machine_rela_relative both do
`*reloc_addr += ...`; however, on sparc64, elf_machine_rela does +=, but
elf_machine_rela_relative just does =.

For RELA, the normal thing to do is of course =, as the only addend comes from
the relocation entry itself. However, my understanding is that Solaris had a
buggy dynamic linker which would also add the contents of the location to be
modified, just like REL, and so my guess is that this is why the 32-bit code
adds rather than assigns?

Regarding sparc64, up until edac0e8f443c332821a63e4f26e298a1622827fe in 2005,
it would always assign for RELATIVE. However, that commit changed the
elf_machine_rela handling of RELATIVE to add, presumably because it copied
snippets from the sparc32 file, whilst leaving elf_machine_rela_relative alone.
Since RELACOUNT gets set on sparc64, I would expect all RELATIVE relocations to
be handled by elf_machine_rela_relative, so this doesn't have an effect, at
least from my Debian perspective, however having the inconsistent handling on
sparc64 seems like a source of confusion.

Therefore I am posing two questions:

1. Can we change sparc32 to assign rather than add, or does it need to stay
   like this for compatibility?

2. Can we make sparc64 consistent with itself, and if so, should it be
   assigning or adding?

Regards,
James

[0] https://sourceware.org/ml/binutils/2017-12/msg00061.html