TL;DR
Large, statically linked codebases can produce ELF binaries that grow well beyond several gigabytes, exposing a practical limit caused by 32-bit relative relocations on x86_64. When a callsite lies more than ~2GiB from its target the linker reports overflow; -mcmodel=large is a common workaround but increases code size and register usage.
What happened
The author recounts encountering extremely large ELF binaries in industry-scale repositories — including examples exceeding 25 GiB when debug symbols are included — driven in part by static linking of services. On x86_64, many call instructions use a 32-bit signed relative offset (the CALL opcode e8), which limits the reach of a single relative jump to roughly ±2 GiB. The post walks through a small example: a simple call produces a relocation entry that the linker fixes up; forcing a callee to live more than 2 GiB away triggers linker "relocation out of range" errors. One straightforward mitigation is compiling with -mcmodel=large, which rewrites relative calls into sequences that load a full 64-bit address and perform an indirect call. That approach resolves the relocation overflow but expands each callsite from about five bytes to roughly twelve and consumes a general-purpose register, with attendant trade-offs.
Why it matters
- Link and build failures can appear in very large codebases when relative relocations exceed ±2 GiB.
- Workarounds like -mcmodel=large remove the overflow but increase binary size and instruction bytes, affecting cache and code density.
- The change from short relative calls to absolute-indirect sequences also consumes registers, potentially altering runtime behavior.
- Large static binaries are a practical problem for organizations that prefer static linking to simplify deployment and startup.
Key facts
- Author observed ELF binaries larger than 25 GiB in industry codebases (including debug symbols).
- x86_64 relative CALL opcode (e8) uses a signed 32-bit offset, limiting reach to roughly ±2 GiB.
- Relocation information in object files (e.g., readelf output) tells the linker where to patch relative offsets.
- Linkers such as lld will emit errors like 'relocation … out of range' when a relocation exceeds ±2 GiB.
- Using -mcmodel=large converts relative calls into sequences that load a 64-bit absolute address and perform an indirect call.
- The absolute-indirect sequence shown increases a callsite from about 5 bytes to about 12 bytes and uses a general-purpose register (example used %rdx).
- The author disabled asynchronous unwind tables (-fno-asynchronous-unwind-tables) in the demo to avoid other overflow data.
- The post references further technical discussion of code models and mentions a blog by @maskray (author of lld) for deeper detail.
What to watch next
- More technical follow-ups from the author (the post states 'More to come in subsequent writings').
- Whether toolchains or linker defaults change to better handle massive codebases: not confirmed in the source.
- Whether real-world performance (IPC, caches, regressions) measurably degrades under -mcmodel=large at scale: not confirmed in the source.
Quick glossary
- ELF: Executable and Linkable Format — a common file format for executables, object code, shared libraries and core dumps on Unix-like systems.
- Relocation: Metadata in object files that tells the linker how to adjust instruction operands or data addresses when combining objects into a final binary.
- Static linking: A build approach that includes library code directly into the executable at link time, producing a standalone binary.
- -mcmodel=large: A compilation/linking option on x86_64 that allows code and static data to be placed beyond the 2 GiB range by using absolute addressing sequences.
- Relative CALL (e8 opcode): An x86_64 instruction encoding that performs a call using a signed 32-bit offset from the next instruction, limiting reach to ±2 GiB.
Reader FAQ
What is the "2GiB relocation barrier"?
It refers to the reach limit of 32-bit signed relative relocations on x86_64 (for example, the CALL e8 opcode), which can only jump roughly ±2 GiB.
Why do some binaries become tens of gigabytes?
In the examples cited, heavy use of static linking across very large codebases — plus debug symbols — can produce ELF files measured in tens of gigabytes.
Does -mcmodel=large solve the problem?
It allows the linker to place code outside the ±2 GiB window by emitting absolute-indirect call sequences, but it increases instruction bytes per call and uses a register, with performance and size trade-offs.
Are there benchmarked performance regressions for -mcmodel=large?
The author says they had difficulty building a convincing benchmark and does not present definitive measured regressions in the source.
A problem I experienced when pursuing my PhD and submitting academic articles was that I had built solutions to problems that required dramatic scale to be effective and worthwhile. Responses…
Sources
- Binaries
- Hardening ELF binaries using Relocation Read-Only …
- ELF Files Unmasked: A Deep Dive into the Structure of …
- ELF relocatable object exporter, part 2 #6102
Related posts
- Z80-μLM: Conversational AI Shrunk to a 40KB CP/M .COM Binary
- Exploring High-Speed GPU Interconnects Using Radio Links for Data Centers
- Mockito maintainer to step down after a decade over agent, Kotlin issues