Re: Inconsistent R_SPARC_RELATIVE addend handling

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 08/12/2017 09:29, James Clarke wrote:
> 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?
Will it break old binaries when running against a patched loader? If it is 
the case I think we will need to either add a workaround on ld.so or work on 
binutils to avoid such issue.

>From [1] on the same thread it seems Alas has created a workaround on binutils
to zero the contexts of got for such cases.  I even more inclined to let
as is on GLIBC and proper document is on sparc32 loader code this issue. 

Even if is the case where binutils is only generating such relocation on newer
releases (as indicated by Alan's comment about ec1acaba commit and it would 
indicate that we might now trigger this issue in old binaries) I am not sure 
if other non gnu linker might be relying on this behaviour.
 
> 
> 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
> 

AFAIU sparc64 is doing what elf_machine_rela_relative is suppose to do 
(assigning). If the idea is to make it consistent with sparc32, will change 
to adding break old binaries? Again if it is so I would prefer to not
change sparc64.

And please follow H.J. Lu suggestion and open a bug report.

[1] https://sourceware.org/ml/binutils/2017-12/msg00071.html