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

[H.J. Lu]

On Fri, Jan 7, 2022 at 5:55 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> 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.

Fixed in the v2 patch.

> >
> > % ~/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.



-- 
H.J.