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

[Eyal Itkin]

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

I was never good at naming. Any name that will be accepted by this forum
is more than fine by me. Please note this anyway only applies at the code
and testing level, as the user-facing CLI flag doesn't mention this name.

> The main idea of the ld -r modifier, if I understand correctly, is to
> constrain symbol bindings based on visibility.

As mentioned in the thread you linked to, and in my technical paper that
started said thread, there are two goals for this effort:
1. As in the shared-library case, apply symbol visibility so to hide internal
library functions by converting them to STB_LOCAL.
2. Allow the ability to strip symbols of internal functions so to avoid exposing
them at the binary level.

The "strip" utility will not be able to strip said symbols as long as they
are tied to a relocation, hence the motivation to resolve said relocations.
Again, as is done in shared objects.

I am aware of the limitations for such relocation resolution, hence the
code-level check that skip it for cross-section relocations (as was also
added to the testsuite) and which were added following your comment
on the thread. It is possible that I indeed missed some code-level checks
to enforce some of the constraints you mentioned as I am new to this
code base. As is mentioned at the commit title (RFC) I will appreciate
any feedback and assistance in implementing my suggestion, as this
current revision is still only a draft.

> Note that ld -r combines sections with the same name, which degrades
> section garbage collection

The flag that is being introduced by this commit is the --finalize-locals
flag, which is added on top of "ld -r" yet does not restrict ld (or the user)
from adding additional flags as they see fit. In the testsuite there is
an example also with ffunction-sections. Hence, user are free to use
the --unique flag, unless I'm missing some restriction that it imposes
on the design or implementation.

>> Many scenarios prevent relocation resolution:
I am aware of that, yet many of the scenarios mentioned are also less
relevant for the case at hand (internal function calls). The goal is a
best effort approach for removing the internal function names at the
code level, the suggestion is not aiming to be a silver bullet that will
handle all cases.

Given the positive overall notion in the generic-abi thread in favor of
submitting this proposal as a patch to GNU ld, I indeed adjusted my
draft and submitted said patch. I will gladly adjust whatever needed
in the patch so to polish this suggested feature, and will more than
appreciate feedback from maintainers who are more familiar with
the code base than I am.


On Sat, Oct 11, 2025 at 9:13 PM Fangrui Song <maskray@sourceware.org> wrote:
>
> 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.