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

[Matthieu Longo]

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

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.

Matthieu