[RFC] Allocate generic section header flag SHF_LARGE (0x1000)

15 views
Skip to first unread message

Pranav Kant

unread,
Sep 18, 2026, 1:32:46 PM (5 days ago) Sep 18
to Generic System V Application Binary Interface

Hi,


We'd like to propose new section flag SHF_LARGE As program text and data sizes continue to scale, linking relocatable objects built with differing code models has become common due to ubiquity of prebuilt small code model objects. While the default small code model restricts symbol references to a limited displacement range (typically +/-2 GiB), the large code model lifts these bounds. To avoid relocation overflow when mixing code models—such as linking prebuilt small-model runtime libraries with large-model application code—the link editor must identify sections which can be placed outside the reachable address window of small-model relocations.


Currently, this capability is only standardized under the x86-64 psABI via the processor-specific flag SHF_X86_64_LARGE (0x10000000). However, the underlying challenge of code-model interoperability and placing large sections outside default small-model reach is not machine-specific—it applies equally to architectures like AArch64, RISC-V, and others. Rather than treating this as a machine-specific problem, this proposal simply generalizes an existing, well-established feature from the x86-64 psABI to the generic ABI by defining a processor-independent section flag:


    #define SHF_LARGE  (1 << 12)  /* 0x1000 */


Under this scheme, target psABIs may adopt SHF_LARGE to denote sections eligible for placement outside the displacement window of small-model relocations. For x86-64, toolchains may treat SHF_LARGE and the legacy SHF_X86_64_LARGE as equivalent for backward compatibility.


There are a few alternatives as listed below but using the section flag is a proven mechanism to address this common challenge that spans multiple architectures as binaries scale. It gives the link editor guaranteed semantic information to make placement decisions without having to interpret section names or content.


Alternatives considered:

1. Only sections with .l* prefix are considered large by the linker. 


We already do this for architectures with GP registers (RISC-V, MIPS, etc.) that support small data (.sdata, .sbss). We could do this for all known .l* sections (.ltext, .ldata, .lrodata, .lbss) for other architectures that are likely to have large binaries (X86-64, AArch64, RISC-V).


Cons:

- While a broad .l* generalization introduces false positives with legitimate sections such as (.literal, .logging, etc.), a strict-allowlist of only .ltext, .ldata, .lbss cannot handle custom, vendor-specific sections (eg: CUDA’s .nv_fatbin) that can be considered large.

- Renaming sections to add .l prefix breaks tools that relies on section names and linker-generated symbols __start__, __stop__ symbols.


2. Add it as the psABI flag.


Cons:

- SHF_MASKPROC is defined as 0xf0000000. With only three total bits available (excluding SHF_EXCLUDE), defining it as psABI flag in these already-scarce slots is not good use of space. This was discussed to add it to psABI for AArch64


3. Use default linker scripts for such placement decisions


Cons:

- Whether a section contains code/data that can safely reside outside default small-model reach is a property known by the producer (the compiler, source author, or precompiled static library). Linker scripts are maintained by the consumer (the final binary target owner). Requiring final binary owners to keep track of every section quickly breaks large monorepos with several heterogeneous targets.

- There are several tools (objcopy, profiler tools, post-link tools like BOLT, Propeller, etc.) that operate directly on object files or final binaries. Not keeping this property together in the object file means these tools will have no way to identify LARGE sections.

- Using linker scripts is not easy to define such placement. You have INSERT BEFORE/AFTER B clauses that can depend on the existence of non-existing section B.


[1] https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models 


References:

2020 generic-abi thread to propose something similar 

Proposed large code model changes for x86 

Discussions to have SHF_LARGE for AArch64 psABI


Reply all
Reply to author
Forward
0 new messages