| Message ID | 20220107190631.309790-1-hjl.tools@gmail.com |
|---|---|
| Headers | show |
| Series | ld: Implement DT_RELR for x86 | expand |
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? > 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.
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. > > 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.
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? % ~/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);
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; }
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.