[PATCH v9 03/19] Object Attributes v2: new abstractions for subsections and attributes

[Jan Beulich]

On 29.10.2025 13:19, Matthieu Longo wrote:
> On 2025-10-29 11:45, Jan Beulich wrote:
>> On 29.10.2025 12:31, Matthieu Longo wrote:
>>> On 2025-10-29 07:37, Jan Beulich wrote:
>>>> On 28.10.2025 18:33, Matthieu Longo wrote:
>>>>> On 2025-10-24 14:05, Jan Beulich wrote:
>>>>>> On 01.09.2025 18:56, Matthieu Longo wrote:
>>>>>>> +int +_bfd_elf_obj_attr_subsection_v2_cmp (const
>>>>>>> obj_attr_subsection_v2 *s1, +				     const
>>>>>>> obj_attr_subsection_v2 *s2) +{ +  int res = strcmp (s1->name,
>>>>>>> s2->name); +  if (res != 0) +    return res; + +  /* Giving to
>>>>>>> the optionality a higher priority than the encoding is +
>>>>>>> artificial.  Its only purpose is to give a total ordering to
>>>>>>> a +     collection of subsections.  */ +  if (!s1->optional &&
>>>>>>> s2->optional) +    return -1; +  else if (s1->optional && !s2-
>>>>>>>> optional) +    return 1; + +  if (s1->encoding < s2-
>>>>>>>> encoding) +    return -1; +  else if (s1->encoding > s2-
>>>>>>>> encoding) +    return 1; + +  return 0; +}
>>>>>>
>>>>>> I can't bring comment (ahead of the function) and code in line
>>>>>> with one another: You're - not comparing attributes, but
>>>>>> attribute sub-sections,
>>>>>
>>>>> It seems to me that I copy-pasted the description for somewhere
>>>>> else, but messed up the rewriting. This is a mistake of mine.
>>>>> Sorry for the confusion.
>>>>>
>>>>> The function compares subsections based on their properties, not
>>>>> their content (i.e. the list of attributes), the goal being to
>>>>> obtain a total ordering in a collection of subsections. Another
>>>>> comparison operator is used to sort the attributes inside a
>>>>> subsection: _bfd_elf_obj_attr_v2_cmp.
>>>>>
>>>>>> - not comparing all attributes of the sub-section, - how
>>>>>> "encoding" and "optional" sort seems entirely arbitrary, i.e. I
>>>>>> cannot make sense of "less" or "greater" there (numeric values
>>>>>> could easily be flipped around as long as these are only
>>>>>> internal representations).
>>>>>
>>>>> Indeed the values themselves don't really matter. The core idea is
>>>>> to provide a comparison operator with the required properties so
>>>>> that there is a total order after the sorting.
>>>>>
>>>>> When the linker loads the OAs of two different object files, the
>>>>> easiest way to merge them is to have the collection sorted,
>>>>> otherwise the merge algorithm would be more complicated and should
>>>>> be based on a hashing mechanism.
>>>>>
>>>>>> Thinking about it, the first two points make me wonder whether
>>>>>> "attribute" here isn't the same as what the entire series is
>>>>>> about. In which case it may help to disambiguate things.
>>>>>>
>>>>>
>>>>> Here is the fixed description. Please let me know if it is clear
>>>>> enough.
>>>>>
>>>>> /* Compare two object attribute subsections based on all their
>>>>> properties. This operator can be used to obtain a total order in a
>>>>> collection. Return an integer indicating the result of the
>>>>> comparison, as follows: - 0, if S1 and S2 are equal. - a negative
>>>>> value if S1 is less than S2. - a positive value if S1 is greater
>>>>> than S2.
>>>>>
>>>>> NB: the scope is computed from the name, so is not used for the
>>>>> comparison.  */
>>>>>
>>>>> int _bfd_elf_obj_attr_subsection_v2_cmp (const
>>>>> obj_attr_subsection_v2 *s1, const obj_attr_subsection_v2 *s2) {
>>>>> int res = strcmp (s1->name, s2->name); if (res != 0) return res;
>>>>>
>>>>> /* Note: the comparison of the encoding and optionality of
>>>>> subsections is completely arbitrary.  Numeric values could
>>>>> completely being flipped around, it would not matter.  Also,
>>>>> giving to the optionality a higher priority than the encoding is
>>>>> artificial.  The searched properties for this comparison operator
>>>>> are reflexivity, transitivity, antisymmetry, and totality in order
>>>>> to achieve a total ordering after the sorting of a collection of
>>>>> subsections.  */
>>>>>
>>>>> if (!s1->optional && s2->optional) return -1; else if (s1-
>>>>>> optional && !s2->optional) return 1;
>>>>>
>>>>> if (s1->encoding < s2->encoding) return -1; else if (s1->encoding
>>>>>> s2->encoding) return 1;
>>>>>
>>>>> return 0; }
>>>>
>>>> This is much better, yes. However, the arbitrary nature of the
>>>> ordering (i.e. what "less" and "greater" really mean) still concerns
>>>> me. If this is arbitrary, it could be altered going forward. If it
>>>> was altered, would cross operation (old gas + new ld or vice versa)
>>>> still function correctly, seeing that you say "the easiest way to
>>>> merge them is to have the collection sorted"? My implication from
>>>> this is that linker and assembler will need to agree on the sorting
>>>> criteria used. But perhaps there's some misunderstanding on my part.
>>>>
>>>> Jan
>>>
>>> The merge always sorts the subsections and attributes, and never assumes
>>> that the object already contains sorted OAs.
>>>
>>> See in the description of patch 12/19:
>>>
>>> * Phase 1, map: successive per-file operations applied on the list of
>>>     compatible input objects.
>>>     ...
>>>     3. Sorting of the subsections and object attributes. Further
>>>        operations rely on the ordering to perform some optimization in
>>>        the processing of the data.
>>>
>>> This is the function containing the sorting:
>>>
>>> /* Merge duplicated subsections and object attributes inside a same object
>>>      file.  After a call to this function, the subsections and object
>>> attributes
>>>      are sorted.  */
>>> static bool
>>> oav2_file_scope_merge_subsections (bfd *abfd)
>>>
>>> If the ordering nature were to be altered going forward, it won't be an
>>> issue as it is internal to ld, and ld only requires a sorted collection
>>> with a total order. The ordering nature does not really matter.
>>
>> Can you make it explicit then in commentary that the (arbitrary) criteria
>> by which you sort are purely an internal thing, i.e. have no effect on the
>> representation in files?
>>
>> Jan
> 
>    /* Note: The comparison of the encoding and optionality of subsections
>       is entirely arbitrary.  The numeric values could be completely flipped
>       around without any effect.  Likewise, assigning higher priority to
>       optionality than to encoding is artificial.  The desired 
> properties for
>       this comparison operator are reflexivity, transitivity, antisymmetry,
>       and totality, in order to achieve a total ordering when sorting a
>       collection of subsections.
>       If the nature of this ordering were to change in the future, it would
>       have no impact on the final merged result in the output file. 

"no impact" as in what the words say, or "no functional impact" (but e.g.
testsuite expectations might still need adjusting)? Asking specifically
because of ...

> Only the
>       order of the serialized subsections would differ, which does not 
> affect
>       the interpretation of the object attributes.

... this further sentence.

>       Similarly, the ordering of subsections and attributes in an input file
>       does not affect the merge process in ld.  The merge process never 
> assumes
>       any particular ordering from the input files, it always sorts the
>       subsections and attributes before merging.  This means that using an
>       older version of gas with a newer ld is safe.

Hopefully also the other way around (as long a no new features are used
that the older ld didn't know of)?

Jan

>       In conclusion, the (arbitrary) criteria used to sort subsections 
> during
>       the merge process are entirely internal to ld and have no effect 
> on the
>       merge result.  */
> 
> What about this ?
> 
> Matthieu