[PATCH v8 12/19] Merge of Object Attributes v2 during linkage (generic logic)

[Jan Beulich]

On 27.08.2025 17:39, Matthieu Longo wrote:
> On 2025-08-22 10:50, Jan Beulich wrote:
>> On 15.07.2025 13:39, Matthieu Longo wrote:
>>> This patch adds all the generic logic to the linker to process OAv2.
>>> The linker is an "advanced" consumer of OAv2. After parsing, it
>>> deduplicates them, merge them, detect any compatibility issues,
>>> and finally translate them to GNU properties.
>>>
>>> ** Overall design
>>>
>>> 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.
>>>
>>> * 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 unsupported/invalid subsections and attributes.
>>
>> May a linker legitimately remove anything? (Instead I would have hoped
>> for some forward compatibility.)
> 
> If a subsection is unknown, the linker does not how to merge it because 
> the merge policy of the subsection is unknown.
> 
>  From there, what to do with the data ?
> 
> 1. Keeping the data from several files and appending them without 
> understanding of what they mean ? It might lead the linker to create 
> invalid data in the OAv2 section, or at least something that does not 
> make any sense for a more recent linker that should have been able to 
> understand them.
> 
> 2. a) If a subsection is marked as required, and the linker does not 
> understand it, the linker errors and cannot link the objects. The 
> failure is justified.
> b) If a subsection is marked as optional, and the linker does not 
> understand it, the subsection is optional so it means that it can safely 
> discard it (while emitting a warning/info message or nothing).
> 
> So yes, I would say that the linker is legitimate to remove anything 
> from the metadata in the input objects if it is not required.
> I don't think that forward compatibility is possible here.

Well, okay, if that's the intention of the spec, then so be it. Feels
to me like the spec is falling short of properly dealing with forward
compatibility (to the extent possible).

Jan