[Bug ld/20402] New: ld.bfd for AArch64 emits R_AARCH64_RELATIVE relocations against SHN_ABS symbols

[ard.biesheuvel at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20402

            Bug ID: 20402
           Summary: ld.bfd for AArch64 emits R_AARCH64_RELATIVE
                    relocations against SHN_ABS symbols
           Product: binutils
           Version: 2.28 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: ard.biesheuvel at linaro dot org
  Target Milestone: ---

ld.bfd in -pie mode will 'optimize' away a R_AARCH64_ABS64 relocation against a
hidden SHN_ABS symbol by replacing it with a R_AARCH64_RELATIVE relocation,
which obviously makes the resulting value in the place dependent on the load
offset rather than fixed.

Instead, I would expect either the relocation to be preserved as a
R_AARCH64_ABS64 relocation to be resolved at load time, or be optimized away
completely, since the symbol is hidden and therefore not preemptible and could
thus be fully resolved at link time.

I don't have a small test case handy (I found this while working on KASLR for
arm64 Linux), but the following hunk fixes the problem completely for me: it
not only prevents the R_AARCH64_RELATIVE relocation from being emitted, but it
fully resolves the relocation and puts the correct 64-bit absolute value in the
place in the ELF binary.

diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c
index 3435a3d67339..d1068f56c4ee 100644
--- a/bfd/elfnn-aarch64.c
+++ b/bfd/elfnn-aarch64.c
@@ -5191,7 +5191,8 @@
                   && h->dynindx != -1
                   && (!bfd_link_pic (info)
                       || !SYMBOLIC_BIND (info, h)
-                      || !h->def_regular))
+                      || !h->def_regular
+                      || sym->st_shndx == SHN_ABS))
            outrel.r_info = ELFNN_R_INFO (h->dynindx, r_type);
          else
            {
(

-- 
You are receiving this mail because:
You are on the CC list for the bug.