[Bug dynamic-link/31541] rtld: Support DT_CREL relocation format

["i at maskray dot me" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31541

--- Comment #1 from Fangrui Song <i at maskray dot me> ---
Stefan O'Rear has developed a musl patch for quantitative assessment
https://0x0.st/XsrV.diff 

> This resolves DT_CREL relocations in dynamically linked executables and
shared libraries, and for non-relative relocations in the dyanmic linker
and static PIE. It does not support DT_CREL for relative relocations in
static PIE and the dynamic linker itself; if DT_CREL is used in static
PIE or the dynamic linker, DT_RELR must also be used.

I've checked lib/libc.so size w/ and w/o CREL support.

* (w/o CREL support) orig: 782064; relr: 780504
* (w/ CREL support) orig: 782736; relr: 781184; relr+crel: 780704

In an x86-64 `-O2` build, CREL support linked with `-z pack-relative-relocs -z
crel` increases the size of `libc.so` by just 200 bytes (0.0256%) compared to a
non-CREL build with `-z pack-relative-relocs`.

---

In glibc, elf/dynamic-link.h ELF_DYNAMIC_RELOCATE has extra complexity because
DT_JMPREL processing is wired into DT_REL/DT_RELA. This is related to the
SPARC:

  /* On some machines, notably SPARC, DT_REL* includes DT_JMPREL in its
     range.  Note that according to the ELF spec, this is completely legal!

     We are guaranteed that we have one of three situations.  Either DT_JMPREL
     comes immediately after DT_REL*, or there is overlap and DT_JMPREL
     consumes precisely the very end of the DT_REL*, or DT_JMPREL and DT_REL*
     are completely separate and there is a gap between them.  */

If this is untangled, CREL support can probably be straightforwardly added.

Since libc.so.6, libpthread.so.0, etc have many non-relative relocations. I
believe RELR+CREL built glibc would be smaller without CREL support :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.