Home Original page

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

Matthieu Longo matthieu.longo@arm.com
Wed Aug 27 15:39:24 GMT 2025 
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.)
> 
> Jan

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.

Matthieu
More information about the Binutils mailing list