[PATCH v4 17/22] gnu directives: add support for gnu_attribute and gnu_subsection in OAv2 context

[Jan Beulich]

On 04.07.2025 18:32, Matthieu Longo wrote:
> On 2025-07-04 15:28, Matthieu Longo wrote:
>> On 2025-07-04 11:38, Richard Earnshaw (lists) wrote:
>>> On 04/07/2025 10:39, Jan Beulich wrote:
>>>> Further, why (having looked at the later patch) overall three 
>>>> #define-s when one
>>>> (TC_OBJ_ATTR) could do (expanding to 0 or the desired version)? 
>>>> Unless of course
>>>> you expect targets might want support for multiple versions.
>>>
>>> It's certainly plausible.
>>>
>>> R.
>>
>> Yes, one target should be able to support multiple versions of OAs, so 
>> we need more than one define.
>>
>> If I follow your idea, you would like HAVE_OBJ_ATTR to become 
>> TC_OBJ_ATTR. How would you name the existing HAVE_OBJ_ATTR_v1 and 
>> HAVE_OBJ_ATTR_v2 ? TC_OBJ_ATTR_v1 and TC_OBJ_ATTR_v2 ?

Yes. I remain unconvinced we need three arch-settable #defines, though.
How about (in common code)

#define TC_OBJ_ATTR_v1 (1 << 0)
#define TC_OBJ_ATTR_v2 (1 << 1)

and in tc-*.h

#define TC_OBJ_ATTR TC_OBJ_ATTR_v<N>

> Just to clarify something regarding your proposition.
> If we keep the current approach defining HAVE_OBJ_ATTR_v1 and 
> HAVE_OBJ_ATTR_v2 according to the value of TC_<arch>,
>  > Why is this done here, rather than in each target's tc-<arch>.h?
> So you would like to move the 3 definitions to tc-<arch>.h. Is this 
> correct ?

As per above - ideally just one of them, but in your scheme (not sure
how it would actually end up) perhaps more.

> Should I also introduce those guards as soon as I move the code into a 
> new file for object attributes (currently gas/attr.[h|c]), in the same 
> patch ? => "gas: move code for object attribute parsing into attr.c"

Yes, I think code moved to the new file should be guarded from the
beginning (as long as things keep building fine at every patch boundary).

Jan