[PATCH v1 02/14] Object Attributes v2: new abstractions for subsections and attributes

[Jan Beulich]

On 24.04.2025 18:34, Matthieu Longo wrote:
> On 2025-03-28 10:57, Jan Beulich wrote:
>> On 21.03.2025 18:14, Matthieu Longo wrote:
>>> From: Richard Ball <richard.ball@arm.com>
>>>
>>> This patch lays the groundwork for the support of Object Attributes v2 (OAv2).
>>> OAv2 is an enhancement of OAv1. They retain successful aspects of OAv1, define
>>> the relationship between object attributes and existing GNU properties, separate
>>> architectural requirements from software ABI requirements, and simplify the
>>> format to make it easier for OAv2 consumers to parse, and skip subsections and
>>> attributes. Interestingly, OAv2 have only one scope: the whole relocatable file
>>> where they were specified. For the reason behind this choice, see [1], "Build
>>> attributes at file scope only". This document also provides more insights into
>>> the design rationale for OAv2.
>>>
>>> Even if OAv2 was designed primarily for AArch64, this implementation splits the
>>> generic core logic from the backend-specific one, and aims at facilitating OAv2
>>> adoption by others backend. This logic will apply for any subsequent OAv2 patch.
>>
>> While at the same time for a majority of targets this will all be dead code.
>>
>> While being unconvinced of the approach for now, I'll at least give some
>> general comments (many / most applicable throughout the series then).
>>
> 
> The idea is to make available OAv2 for others targets at a "low cost".
> 
> Ideally, the architecture should look like a "sandwich" composed of:
> - a deserialization layer toward a generic abstraction covering OAv1, 
> OAv2(, and even GNU properties because it is basically the same thing).
> - a generic middle end merging the generic attributes.
> - a serialization layer toward the latest version of OA + GNU properties 
> as we cannot really switch to all-OA because of performance concerns in 
> the runtime linker. I am not 100% convinced by this performance concern 
> argument, but the long history with GNU properties tells us that they 
> are not going to go away soon.
> 
> This requires a middle-end abstraction agnostic of V1 or V2. It also 
> requires managing dependencies between tags (there are some craziness in 
> OAv1 for AArch32).
> 
> Unfortunately building this middle end is a lot of work, and I don't 
> have the allocated time for it.
> 
> I am interested in your thoughts about the above, and I can provide more 
> details if you wish.

Such an abstraction may indeed by nice, but how does all of what you wrote
relate to me pointing out that all of this new code is going to be unused
baggage for (presumably) the vast majority of architectures? Are you kind
of suggesting that many other architectures may want to adopt this model?
If so, was this brought up with any of the respective maintainers (or,
perhaps even more important as a first step, maintainers of the psABI-s)?

Jan