[PATCH v8 04/19] gas: implement parsing of object attributes v2

[Matthieu Longo]

On 2025-08-15 11:27, Jan Beulich wrote:
> On 15.08.2025 11:51, Matthieu Longo wrote:
>> On 2025-08-15 10:41, Jan Beulich wrote:
>>> On 15.08.2025 11:40, Matthieu Longo wrote:
>>>> On 2025-08-15 09:18, Jan Beulich wrote:
>>>>> On 14.08.2025 18:41, Matthieu Longo wrote:
>>>>>> On 2025-08-14 16:40, Jan Beulich wrote:
>>>>>>> On 14.08.2025 17:29, Matthieu Longo wrote:
>>>>>>>> On 2025-08-06 16:20, Richard Earnshaw wrote:
>>>>>>>>> On 06/08/2025 16:05, Jan Beulich wrote:
>>>>>>>>>> On 06.08.2025 16:02, Matthieu Longo wrote:
>>>>>>>>>>> On 2025-07-31 15:40, Jan Beulich wrote:
>>>>>>>>>>>> On 15.07.2025 13:39, Matthieu Longo wrote:
>>>>>>>>>>>>> The usage of those directives will error if the following requirements
>>>>>>>>>>>>> are breached:
>>>>>>>>>>>>> - If the subsection X has been previously declared, the
>>>>>>>>>>>>> comprehension and
>>>>>>>>>>>>>         encoding parameters of the current .aeabi_subsection that
>>>>>>>>>>>>> redeclares X
>>>>>>>>>>>>>         have to match with the previous declaration.
>>>>>>>>>>>>
>>>>>>>>>>>> If I'm reading things right, such a re-declaration still needs to
>>>>>>>>>>>> provide
>>>>>>>>>>>> not only the name, but also "comprehension" and encoding. Just for
>>>>>>>>>>>> it to
>>>>>>>>>>>> be checked against the earlier decl. As with ordinary sections, I think
>>>>>>>>>>>> it would be nice if an "incomplete" re-decl would be accepted.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Unlike code where there is a genuine usecase of switching to and from
>>>>>>>>>>> sections, all the build attributes are in a file scope so there is not
>>>>>>>>>>> really much need to split them up. For instance, GCC on AArch64 targets
>>>>>>>>>>> will dump them all in one chunk.
>>>>>>>>>>> No strong opinion against the idea, so I don't mind adding it if you
>>>>>>>>>>> think that it would be valuable for users.
>>>>>>>>>>>
>>>>>>>>>>> NB: This would require amending the spec, and discussing it with LLVM.
>>>>>>>>>>
>>>>>>>>>> Well, I don't know how things will typically look in assembly files not
>>>>>>>>>> produced by a compiler or alike. If "re-declarations" aren't expected to
>>>>>>>>>> be common, perhaps leave as is. Question then is whether to permit
>>>>>>>>>> "re-declarations" at all; disallowing them would simplify a few things.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I wouldn't expect a compiler to need to do redeclarations, but I could
>>>>>>>>> envisage a use case for this when using include files to build up a
>>>>>>>>> file.  In that case, I'd expect the attributes to be stand-alone and add
>>>>>>>>> the attributes specific to each hunk.  If you wanted to have it work
>>>>>>>>> where only the first specification of a section defined the flags, you'd
>>>>>>>>> end up either with a pre-declaration of the section, or having some
>>>>>>>>> weird constraint on include order.
>>>>>>>>>
>>>>>>>>> So I certainly think we need checking of the headers, but perhaps we'd
>>>>>>>>> also want checking of the added attributes as well (unless gas were to
>>>>>>>>> be able to merge re-declarations of a single attribute): for example,
>>>>>>>>> changing an attribute value from 3 to 2 might be completely incorrect,
>>>>>>>>> but keeping 3 might not be correct either - it depends very much on the
>>>>>>>>> context.
>>>>>>>>
>>>>>>>> With the current implementation, gas raises an error if an attribute is
>>>>>>>> redeclared with a different value.
>>>>>>>> Merging would be the ideal, but since there is no use case for it now,
>>>>>>>> could we delay the merge implementation to when a real use case will
>>>>>>>> emerge ?
>>>>>>>
>>>>>>> I guess that's going to be okay. I'd like to ask though that you mention
>>>>>>> the aspect in the description then.
>>>>>>
>>>>>> It is already here in the description.
>>>>>>
>>>>>> The usage of those directives will error if the following requirements
>>>>>>      are breached:
>>>>>> - If the subsection X has been previously declared, the comprehension
>>>>>> and encoding parameters of the current .aeabi_subsection that redeclares
>>>>>> X have to match with the previous declaration.
>>>>>> - The type of the value set via .aeabi_attribute has to align with the
>>>>>> current subsection.
>>>>>> - If the tag N has already been declared for the current subsection, a
>>>>>> later assignment to tag N is tolerated only if the newly set value is
>>>>>> equal to the former one.
>>>>>>
>>>>>> I guess that the issue is the density and length of the description.
>>>>>
>>>>> No, the issue is that what I'm asking for isn't there: I'm after you
>>>>> mentioning that these strict requirements could in principle be relaxed,
>>>>> or in other words, that the checking right now is deliberately more
>>>>> strict than absolutely necessary.
>>>>
>>>> Thanks for the clarification.
>>>>
>>>> Is this description better ?
>>>>
>>>> If the tag N has already been declared for the current subsection, a
>>>> later assignment to tag N is tolerated only if the newly set value is
>>>> equal to the former one. This check is stricter than needed. Ideally,
>>>> the tag N's values should be merged together, and an error should be
>>>> raised only if an incompatibility is detected. Because the attributes
>>>> are set in one chunk by GCC, there is no real use case for such a merge.
>>>
>>> That reads okay to me, yes. Something similar then for subsections?
>>
>> For subsections, no. The parameters have to match as soon as the name
>> matches, so the check need to be strict and no merge is possible.
> 
> Yet my earlier comment were primarily on subsections, comparing the
> situation with the re-declaration of (ordinary) sections. Why is it that,
> once a subsection was declared, it can't be re-entered by just providing
> its name, if the other attributes have to match anyway?
> 
> Jan

I implemented the support for the omission of the comprehension and 
encoding on the subsection directive. You can review it in the next 
revision. I also updated the commit description and the doc.

Here is the amending on the spec: 
https://github.com/ARM-software/abi-aa/pull/230/commits/7e28e0b2c733ed36aefa3f45be7fb27b04f709b9.

Matthieu