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

[Matthieu Longo]

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.
> 
> Jan

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.

Matthieu