[PATCH v8 02/19] gas: move code for object attribute parsing into obj-elf-attr.c

[Jan Beulich]

On 04.08.2025 12:37, Matthieu Longo wrote:
> On 2025-07-31 14:14, Jan Beulich wrote:
>> On 15.07.2025 13:39, Matthieu Longo wrote:
>>> --- a/gas/configure.ac
>>> +++ b/gas/configure.ac
>>> @@ -454,6 +454,19 @@ changequote([,])dnl
>>>   	;;
>>>       esac
>>>   
>>> +    # Does the target support Object Attributes ?
>>> +    case ${cpu_type} in
>>> +      arc* | arm* | csky | m68k | mips* | msp430 | powerpc* \
>>> +      | riscv* | s390* | sparc* | tic6x)
>>> +	for f in config/obj-elf-attr.o; do
>>> +	  case " $extra_objects " in
>>> +	    *" $f "*) ;;
>>> +	    *) extra_objects="$extra_objects $f" ;;
>>> +	  esac
>>> +	done
>>> +	;;
>>> +    esac
>>> +
>>>       # Any other special object files needed ?
>>>       case ${cpu_type} in
>>
>> Looking at patch 04 I came to wonder: How does this limit addition of the
>> extra object file to ELF targets?
> 
> The code in the C file is surrounded by TC_OBJ_ATTR that is not set for 
> targets without no support for object attributes like x86_64. The change 
> in gas/configure.ac ensures that the file is not built.
> 
> After patch 4,
> - for targets with no support for OA, nothing change. obj-elf-attr.c is 
> still not built.
> - for targets supporting only OAv1, the file is included, TC_OBJ_ATTR is 
> set but only TC_OBJ_ATTR_v1 is set. So any OAv2-only code is disabled 
> and won't be compiled.
> - for targets supporting only OAv2, same thing but TC_OBJ_ATTR_v2 is set 
> instead of TC_OBJ_ATTR_v1.
> - if any target decides to migrate to OAv2, they can enable both OAv1 
> and OAv2 to support both for a transition period.

And for (CPU) targets supporting ELF and whatever other format(s), the
enabling of TC_OBJ_ATTR_v<N> is then suitably guarded in tc-*.h? Okay,
that's fine then.

> The addition of the extra object file will always happen when the target 
> supports OA. From my perspective, I don't see much benefit of splitting 
> OAv1 and OAv2 code in three different files (one for the generic code, 
> and the others two for OAv1 and OAv2). The quantity of code seemed too 
> small to do so.
> 
> Since the result is the same after compilation, it seems that your 
> concern is more related to code organization. Please let me know what is 
> your concern.

If no dead code is included, all is fine. It just feels counterintuitive
to me to frame an entire source file by #ifdef, hence why I didn't suspect
that as a "solution".

Jan