Bug#996598: [ld][glibc]: Adopt SHT_RELR/DT_RELR to decrease PIE and shared object size
Source: glibc Severity: wishlist Tags: upstream X-Debbugs-Cc: sylves...@debian.org The SHT_RELR/DT_RELR format encodes relative relocations in a very efficient way (quite usually takes just 3% or smaller space). The size optimization can greatly decrease the virtual memory size of PIE and shared objects with many R_*_RELATIVE relocations. E.g. The clang executable's virtual memory size is 8.2% smaller with SHT_RELR/DT_RELR. The size varies across projects, but I anticipate at least 5% decrease for most projects. % ~/projects/bloaty/Release/bloaty clang.pie.relr -- clang.pie FILE SIZEVM SIZE -- -- [NEW] +163Ki [NEW] +163Ki.relr.dyn +4.9% +32 +5.4% +32.dynamic +2.5% +8 [ = ] 0.shstrtab -99.5% -13.8Mi -99.5% -13.8Mi.rela.dyn -8.3% -13.6Mi -8.2% -13.6MiTOTAL The SHT_RELR/DT_RELR relocation format requires linker and loader support. * On the linkder side, ld.lld has supported .relr.dyn/SHT_RELR/DT_RELR (`--pack-dyn-relocs=relr`) for a long time and the support has been stable since 2019-09 (after I fixed an address oscillating bug). * On the loader (glibc ld.so) side, a patch exists https://sourceware.org/pipermail/libc-alpha/2021-October/131768.html but lack of GNU ld support may impede its adoption among Linux distributions. User support is also important to push the patch forward. (ia64 according to folks isn't an issue. glibc doesn't implement ELFCLASS32 for ia64 AFAICT.) ( Worth noting that the Linux kernel's arm64 port supports SHT_RELR/DT_RELR since 2019. ChromeOS has maintained a local glibc patch since around 2018.) So I file this ticket seeking for support (comment on https://sourceware.org/bugzilla/show_bug.cgi?id=27924). I hope that with sufficient attention from users, someone (e.g. a GNU ld maintainer) will eventually stand up and implement `--pack-dyn-relocs=relr` for GNU ld (https://sourceware.org/bugzilla/show_bug.cgi?id=27923). Even in the absence of GNU ld support, I hope glibc can accept the DT_RELR patch, so that ld.lld users can use `--pack-dyn-relocs=relr`. See also Gentoo: https://bugs.gentoo.org/818376 Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2014699 Arch Linux: https://bugs.archlinux.org/task/72433
Bug#991861: make check has 100+ failures due to `libgcc_s.so.1 must be installed for pthread_cancel to work`
Source: glibc Severity: normal Tags: upstream X-Debbugs-Cc: i...@maskray.me On many(all?) Debian derivatives, when building the upstream glibc, `make check` has 100+ failures due to `libgcc_s.so.1 must be installed for pthread_cancel to work` I filed https://sourceware.org/bugzilla/show_bug.cgi?id=28177 . An upstream maintainer told me that: > Please talk to Debian or Ubuntu about upstreaming their multiarch > patches. The upstream toolchain is consistent in this area. The issue > only happens if you try to do glibc development on a system that has > these custom downstream patches in its system toolchain. > > (Just to be clear, I would like to see these patches upstreamed, it's > just not something I'm sure I can do due to the licensing aspects > involved.) So hope a Debian developer can upstream the path so that a glibc contributor doesn't need to `cp /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 $prefix/bfd/lib/` to make `make check` happy. -- System Information: Debian Release: rodete Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.40-1rodete2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
