[PATCH v11 16/25] OAv2 merge: merging Object Attributes

[Jan Beulich]

On 31.12.2025 00:05, Matthieu Longo wrote:
> The Object Ottributes merge process must handle both optional and
> required subsections. It also treats the first merge of the frozen set
> specially, as the OAv2 list in the input BFD serves as the accumulator
> for subsequent merges.
> 
> ** Optional subsections
> 
> Optional subsections are processed as if merging two ordered sets — by
> iterating linearly through both, checking whether an element of a given
> ordinality is present in the opposite set, and adding it to the
> accumulator. The added diffuculty with subsections and attributes lies
> in the fact that missing elements have default values, and these must be
> merged with existing ones to produce the final value to be stored.
> 
> ** Required subsections
> 
> Required subsections are processed slightly differently from the
> optional subsections, as they cannot be pruned since they are mandatory,
> hence an error will be raised by the linker if it is not recognized.
> 
> For now, the subsection for PAuth ABI is the only one use case, and
> no merge is applied on the values. The values simply need to match.
> This implementation choice might be challenged in the future if required
> subsections can have the same diversity as optional subsections. If the
> case arises, the refactoring to handle this new behavior should consist
> in adding a new merge policy MERGE-EQUAL, or something similar. Some "if
> required" should be added in the optional subsections merge logic to
> error on any missing elements, or mismatch, and messages should also be
> rephrased to point out that the error is for a required subsection.
> 
> ** Important note regarding support for testing
> 
> In order to test this generic logic, AArch64's use cases are not
> offering enough coverage, so a "GNU testing namespace" which corresponds
> to the name of the subsection was introduced. It follows the following
> pattern:
>   gnu_testing_<XXXXXX>_MERGE_<POLICY>
> with:
>   - <XXXXXX>: an arbitrary name for your testing subsection.
>   - <POLICY>: the name of the merging policy to apply on the values in
>     the subsection. The currently supported merge policy are:
>       * _MERGE_AND: bitwise AND applied on numerical values.
>       * _MERGE_OR: bitwise OR applied on numerical values.
>       * _MERGE_ADD: concatenates strings together with a '+' in-between.
>     Note: "_MERGE_ADD" does not make really sense, and will very likely
>     never be used for a real merge. Its only purpose is to test the
>     correct handling of merges with strings.
> Any subsection name matching neither names supported by the backend, nor
> following the pattern corresponding GNU testing namespace will be considered
> unknown and its status set to obj_attr_subsection_v2_unknown. This will
> have for consequence the pruning of this subsection.
> 
> Additionally, the first two tags in gnu_testing namespace, GNUTestTag_0
> and GNUTestTag_1, are known, and so have a name and can be initialized
> to the default value ('0' or NULL) depending on the encoding specified
> on the subsection. Any tags above 1 will be considered unknown, so will
> be default-initialized in the same way but its status will be set to
> obj_attr_v2_unknown. This behavior of the testing tags allows to test
> the pruning of unknown attributes.
> ---
>  bfd/elf-attrs.c    | 874 ++++++++++++++++++++++++++++++++++++++++++++-
>  bfd/elf-attrs.h    |  24 ++
>  bfd/elf-bfd.h      |   9 +
>  bfd/elfxx-target.h |   8 +
>  4 files changed, 904 insertions(+), 11 deletions(-)

Okay with, again, ...

> +/* Append a new default-initialized attribute with the same key as AREF to the
> +   given subsection.  */
> +static void
> +oav2_subsection_append_attr_default (const struct bfd_link_info *info,
> +				     obj_attr_subsection_v2_t *s_abfd_missing,
> +				     const obj_attr_v2_t *a_ref)
> +{
> +  obj_attr_v2_t *new_attr = oav2_attr_default (info, s_abfd_missing, a_ref);
> +  LINKED_LIST_APPEND(obj_attr_v2_t) (s_abfd_missing, new_attr);

the style issue here (and elsewhere) addressed.

Jan