This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Inconsistent R_SPARC_RELATIVE addend handling
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: James Clarke <jrtc27 at jrtc27 dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, "Jose E. Marchesi" <jose dot marchesi at oracle dot com>, Alan Modra <amodra at gmail dot com>, John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>, Rolf Eike Beer <eb at emlix dot com>
- Date: Fri, 8 Dec 2017 03:32:50 -0800
- Subject: Re: Inconsistent R_SPARC_RELATIVE addend handling
- Authentication-results: sourceware.org; auth=none
- References: <5F79BA05-1EEC-4590-B061-8E37579D11A3@jrtc27.com>
On Fri, Dec 8, 2017 at 3:29 AM, James Clarke <jrtc27@jrtc27.com> 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?
>
> 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
>
You should open a glibc bug to track it.
--
H.J.