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

[Matthieu Longo]

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

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 ?

Matthieu