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

[Jan Beulich]

On 29.04.2025 17:27, Richard Earnshaw (lists) wrote:
> On 25/04/2025 09:17, Jan Beulich wrote:
>> 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?
> 
> The existing aarch32 build attributes code was, of course, originally specific to the Arm port.  But grep'ing through gas/config/*.c I see use of "Tag_" in tc-arc.c, tc-arm.c, tc-csky.c, tc-m68k.c, tc-mips.c, tc-msp430.c, tc-ppc.c, tc-riscv.c, tc-sparc.c and tc-tic6x.c, so the code has clearly been useful far beyond the original port.
> 
> The problem at present is that the mid-end code is too close to the individual implementations of attributes.  As of today we already have Arm (aarch32) build attributes and GNU properties.  Both essentially are trying to address related problems: expressing properties of the object code and expected run-time environment.  The build attributes model specified for AArch64 is very similar in concept to that of the original model for aarch32, but it does contain some changes to address some of the short-comings of the older design.  But that now gives us three models of what is, essentially, the same problem that needs solving.
> 
> The BFD way of addressing this type of problem would be to map the various external representations into an internal form that can be handled generically, then mapped back again into whatever is appropriate for the output; that might even involve writing some, or all, of the data out in formats that are different from the format
> used in incoming code (for example, some information encoded in build attributes might need to be emitted in the form of GNU properties for systems using Linux or glibc).
> 
> I guess our hope is that, over time, the existing ports could be adapted to use the generic code we're proposing; but the conversions are not necessarily trivial.  Deserializing and serializing the external attributes into a suitable internal form is not entirely trivial due to evolution of the set of attributes and bugs in some of the attribute definitions (yes, they do exist; mea culpa for some of them 🙂), so I don't think that is something not familiar with the architecture can attempt.  That of course means we would need to keep the existing implementations as well for the time being.
> 
>> 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)?
> 
> I'm not sure I follow this.  The discussion here is about the internal representation in binutils;  not how other psABIs want to represent the data in object files.  The whole point is to try to break the dependency between generic code in binutils and target-specific format externally.

Yes. My question though was whether we can avoid carrying a lot of new dead
(binary) code for most targets in the bfd library, or whether perhaps doing
so is warranted because there already was buy-in from maintainers of other
architectures.

Jan