[PATCH v11 11/25] OAv2 merge: plumbing of generic merge logic during linkage

[Jan Beulich]

On 31.12.2025 00:05, Matthieu Longo wrote:
> This patch adds the plumbing for the OAv2 generic merge logic in the
> linker. The linker is an "advanced" consumer of OAv2. After parsing,
> it deduplicates the attributes, merges them, detects any compatibility
> issues, and finally translates them to GNU properties.
> 
> This patch only prepares the infrastructure required to support that
> processing. All operations described below rely on helpers or stubs,
> and their implementation details will be added in the subsequent
> patches.
> 
> ** Intended pipeline
> 
> Disclaimer: the description below documents the intended processing
> pipeline. This commit only establishes the phases boundaries, and
> call sites. The actual logic of each step is implemented in subsequent
> patches.
> 
> The OAv2 processing pipeline follows a map-reduce pattern. Obviously,
> the actual processing in GNU ld is not multi-threaded, and the
> operations are not necessarily executed directly one after another.
> 
> * Phase 1, map: successive per-file operations applied on the list of
>   compatible input objects.
>   1. Parsing of the OAv2 section's data (also used by objcopy).
>   2. Translation of relevant GNU properties to OAv2. This is required
>      for the backward-compatibility with input objects only marked
>      using GNU properties.
>   3. Sorting of the subsections and object attributes. Further
>      operations rely on the ordering to perform some optimization in
>      the processing of the data.
>   4. Deduplication of subsections and object attributes, and detection
>      of any conflict between duplicated subsections or tags.
>   5. Translation of relevant OAv2 to GNU properties for a forward
>      -compatibility with the GNU properties merge.
>   6. Marking of unknown subsections to skip them during the merge
>      (in phase 2), and to prune them before the output object's
>      serialization (in phase 3).
> 
> * Phase 2, reduce: OAv2 in input objects are merged together.
>   1. Gathering of "frozen" values (=coming from the command-line
>      arguments) into a virtual read-only list of subsections and
>      attributes.
>   2. Merging of OAv2 from an input file and the frozen input.
>   3. Merging of the results of step 2 together. Since the OAv2 merge
>      is commutative and associative, it can be implemented as a reduce.
>      However, GNU ld implements it as an accumulate because it does
>      not support multithreading.
>   Notes: the two merge phases also perform a marking of unsupported/
>   invalid subsections and attributes. This marking can be used for
>   debugging, and also more practically, to drop unsupported optional
>   subsections from the output.
> 
> * Phase 3, finalization of the output.
>   1. Pruning of the unknown / unsupported / invalid subsections and
>      attributes.
>   2. Serialization of OAv2 data (also used by objcopy).
>   Notes:
>    - There is no translation of the merged OAv2 to GNU properties
>      at this stage, as the GNU properties merge process has already
>      all the needed information (translated in step 5 of stage 1) to
>      produce the GNU properties equivalents.
>    - The GNU properties are currently required as the runtime linker
>      does not understand OAv2 yet.
>    - Phase 3 should also include a compatibility check between the
>      final merge result of the current link unit and input shared
>      objects. I opted for postponing this compatibility check, and
>      GNU properties merge will take care of it as it already does.
> ---
>  bfd/elf-attrs.c    | 436 ++++++++++++++++++++++++++++++++++++++++++++-
>  bfd/elf-attrs.h    |  26 +++
>  bfd/elf-bfd.h      |   5 +
>  bfd/elfxx-target.h |   4 +
>  ld/ldelf.c         |   1 +
>  5 files changed, 471 insertions(+), 1 deletion(-)

Okay.

Jan