Re: [PATCH 0/10] ld: Implement DT_RELR for x86

["H.J. Lu" <hjl.tools@gmail.com>]

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.