[PATCH 0/10] ld: Implement DT_RELR for x86
H.J. Lu
hjl.tools@gmail.com
Sat Jan 8 01:55:28 GMT 2022
On Fri, Jan 7, 2022 at 5:31 PM Fangrui Song <i@maskray.me> wrote:
>
> On 2022-01-07, H.J. Lu via Binutils wrote:
> >On Fri, Jan 7, 2022 at 3:46 PM Fangrui Song <maskray@google.com> wrote:
> >>
> >> On 2022-01-07, H.J. Lu via Libc-alpha wrote:
> >> >Hi Nick,
> >> >
> >> >I'd like to enable DT_RELR for x86 in binutils 2.38.
> >> >
> >> >
> >> >H.J.
> >> >---
> >>
> >> Thanks for the patch!
> >>
> >> Is the Clang crash
> >> https://sourceware.org/pipermail/libc-alpha/2022-January/134992.html
> >> fixed now?
> >>
> >
> >It should be fixed. Please try my current DT_RELR branch.
>
> Thanks. It works.
>
> % rm /tmp/out/custom1/clang
> % ninja -C /tmp/out/custom1/clang -v # find the linker command line
> % <linker-command-line> -Wl,--reproduce=/tmp/clang-relassert.tar
> % cd /tmp && tar xf clang-relassert.tar && cd clang-relassert
> # Remove --chroot from response.txt
>
> # Managed to compile a file with the linked clang
> % ~/Dev/binutils-gdb/out/release/ld/ld-new -z pack-relative-relocs @response.txt -o bfd.relr
> % LD_LIBRARY_PATH=/tmp/glibc/lld/lib:/usr/lib/x86_64-linux-gnu /tmp/glibc/lld/lib/ld-linux-x86-64.so.2 ./bfd.relr -c /tmp/c/a.c -O2
>
>
> There are still quite a few even-address R_X86_64_RELATIVE relocations.
> Any idea why they are present?
ld can generate R_X86_64_RELATIVE in elf_x86_64_finish_dynamic_symbol:
else if (bfd_link_pic (info)
&& SYMBOL_REFERENCES_LOCAL_P (info, h))
{
if (!SYMBOL_DEFINED_NON_SHARED_P (h))
return false;
BFD_ASSERT((h->got.offset & 1) != 0);
rela.r_info = htab->r_info (0, R_X86_64_RELATIVE);
rela.r_addend = (h->root.u.def.value
+ h->root.u.def.section->output_section->vma
+ h->root.u.def.section->output_offset);
relative_reloc_name = "R_X86_64_RELATIVE";
}
This case isn't handled yet.
>
> % ~/Dev/binutils-gdb/out/release/binutils/readelf -r bfd.relr
> ...
> Relocation section '.rela.dyn' at offset 0x5fb400 contains 3133 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 000009902608 000000000008 R_X86_64_RELATIVE 9281940
> 000009902610 000000000008 R_X86_64_RELATIVE 7a4d565
> 000009902618 000000000008 R_X86_64_RELATIVE 91acf98
> ...
> Relocation section '.relr.dyn' at offset 0x60f6e0 contains 19910 entries:
> 535577 offsets
> 0000000008f83f58
> 0000000008f83f60
> 0000000008f83f68
> ...
>
> >
> >> > 10/10 ld: Add glibc dependency for DT_RELR
> >> >
> >> > if (!glibc_bfd && startswith (a->vna_nodename, "GLIBC_2."))
> >>
> >> Thanks for adding the GLIBC_ABI_DT_RELR verneed only if GLIBC_2.* exists, this will make
> >> musl/FreeBSD/NetBSD/etc happy.
>
> Does your DT_RELR patch have something like this?
>
> + // Don't allow the section to shrink, otherwise the size of the section can
> + // oscillate infinitely. Trailing 1s do not decode to more relocations.
> + if (entries_.size() < old_size)
> + entries_.resize(old_size, 1);
if (dt_relr_bitmap_count > new_count)
{
/* Don't shrink the DT_RELR section size to avoid section
layout oscillation. Instead, pad the DT_RELR bitmap with
1s which do not decode to more relocations. */
htab->dt_relr_bitmap.count = dt_relr_bitmap_count;
count = dt_relr_bitmap_count - new_count;
for (i = 0; i < count; i++)
htab->dt_relr_bitmap.u.elf64[new_count + i] = 1;
}
--
H.J.
More information about the Binutils
mailing list