https://sourceware.org/bugzilla/show_bug.cgi?id=31475
Bug ID: 31475
Summary: binutils: Support RELLEB relocation format
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
The relocation formats REL and RELA for ELF are inefficient. In a release build
of Clang for x86-64, .rela.* sections consume a significant portion
(approximately 20.9%) of the file size.
I have developed an alternative relocation format (tentatively named RELLEB)
for LLVM/Clang/lld, which yields a significant reduction of 16.7%! (.o file
size)
Elf32_Rel and Elf32_Rela sacrifice flexibility to maintain a smaller size,
limiting relocation types to a maximum of 255. RELLEB allows 2**32 relocation
types, aligning with Elf64_Rel/Elf64_Rela.
---
I have analyzed many architectures including Arm (AArch32/AArch64), Power,
RISC-V, MIPS, RISC-V, z/Architecture, and x86, written a detailed analysis of
the size problem and my solution at
https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf ,
created a generic ABI proposal
https://groups.google.com/g/generic-abi/c/yb0rjw56ORw
and an LLVM proposal
https://discourse.llvm.org/t/rfc-relleb-a-compact-relocation-format-for-elf/77600
---
For binutils, we would need at least these pieces:
* ld
+ handle SHT_RELLEB input sections
+ -r: copy SHT_RELLEB and rewrite
+ (optional; dynamic relocations) -z relleb: use .relleb.dyn instead of
.rel.dyn/.rela.dyn for dynamic
relocations. Can be used together with --pack-dyn-relocs=relr
* readelf
+ -S: recognize SHT_RELLEB
+ -d: recognize DT_RELLEB
+ -r: dump SHT_RELLEB sections
+ (optional: if DT_RELLEB is accepted) dump DT_RELLEB table
* objcopy
+ objcopy seems to convert SHT_REL to SHT_RELA
(https://sourceware.org/bugzilla/show_bug.cgi?id=28035). If SHT_RELLEB is
added, we will need to disable unneeded SHT_RELLEB => SHT_RELA conversion:)
* objdump
+ -r: dump DT_RELLEB
+ -d -r: inline relocations
--
You are receiving this mail because:
You are on the CC list for the bug.
