Home Original page

[PATCH v2] [RFC][ld] Introduce static bundle object support

Fangrui Song maskray@sourceware.org
Sat Oct 11 18:13:56 GMT 2025 
On Fri, Oct 10, 2025 at 5:24 AM Eyal Itkin <eyal.itkin@gmail.com> wrote:
>
> Note: This patch is a draft for review.
>
> Introduce a new "Static Bundle Object" which is a
> relocatable object that supports symbol visibility
> and finalization of local relocations. This format
> is aimed to be incorporated within static archives
> so to replace the current static archives of plain
> object code files that are used to form static
> libraries.
>
> The full discussion about the format is available in the
> generic-abi group that is responsible for the ELF standard:
> https://groups.google.com/g/generic-abi/c/sT25-xfX9yc
>
> Some questions I had about the process itself:
> 1. The patch is architecture dependent given that
> relocations support is found in both bfd/elflink.c AND
> in some arch-specific files (such as bfd/elf64-x86-64.c).
> Hence, what is the standard way for marking some archs as
> not yet supported? And what is the recommended process for
> adding said support (especially given need to test it)?
>
> Signed-off-by: Eyal Itkin <eyal.itkin@gmail.com>

Discussions on the generic-abi thread mentioned that "static bundle
object" is probably not a good name.

The main idea of the ld -r modifier, if I understand correctly, is to
constrain symbol bindings based on visibility.
In my opinion, resolving relocations isn't useful for this purpose, as
I mentioned in my comment at
https://groups.google.com/g/generic-abi/c/sT25-xfX9yc/m/bE-MMmxTAQAJ

    Only a limited set of relocations can actually be resolved in
relocatable files.
    Specifically, this applies to relocations following the (S-P+A)
formula where S refers to a non-ifunc local symbol in the same section
as P.
    This behavior mirrors assembler fixup resolution
(https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers
):

    > Fixup resolution depends on the fixup type:
    >
    > - PC-relative fixups that describe the symbol itself (the
relocation operation looks like S - P + A) resolve to a constant if
sym_a is a non-ifunc local symbol defined in the current section.
    > - relocation_specifier(S + A) style fixups resolve when S refers
to an absolute symbol.
    > - Other fixups, including TLS and GOT related ones, remain unresolved.

    Many scenarios prevent relocation resolution:

    - Cross-section symbol references
    - Symbols with STB_WEAK or STB_GLOBAL binding (due to potential
symbol interposition in shared libraries and linker script symbol
assignments)
    - TLS or GOT-related relocations
    - Relocations potentially requiring PLT entries or range-extension thunks

I've analyzed the following assembly with a patched ld-new

.hidden ext
.hidden hid
.global _start, hid
_start:
hid:
.L1:
  call ext
  call hid
  #mov hid@gotpcrel(%rip), %rax

.section .text,"ax",@progbits,unique,1
  .long .L1 - .
  call .L1

.section .data,"aw"
  .long .L1 - .

% ~/Dev/binutils-gdb/out/debug/ld/ld-new -r a.o --finalize-locals -o
a.fo && readelf -W -r a.fo

Relocation section '.rela.text' at offset 0xf8 contains 2 entries:
    Offset             Info             Type               Symbol's
Value  Symbol's Name + Addend
000000000000000a  0000000100000002 R_X86_64_PC32
0000000000000000 .text + 0
000000000000000f  0000000100000004 R_X86_64_PLT32
0000000000000000 .text - 4

Relocation section '.rela.data' at offset 0x128 contains 1 entry:
    Offset             Info             Type               Symbol's
Value  Symbol's Name + Addend
0000000000000000  0000000100000002 R_X86_64_PC32
0000000000000000 .text + 0

Two relocations are resolved, which is not useful.
ld-new would crash if I add this GOT-related relocation

  mov hid@gotpcrel(%rip), %rax

---

Note that ld -r combines sections with the same name, which degrades
section garbage collection
(shameless plug https://maskray.me/blog/2021-02-28-linker-garbage-collection )
You can use --unique to preserve multiple sections of the same name,
at least for sections from different .o files. However, this doesn't
help with the .text sections in this example.
More information about the Binutils mailing list