[PATCH v11 23/25] gnu directives: gas/readelf tests for gnu attributes v2

[Matthieu Longo]

On 09/01/2026 09:19, Jan Beulich wrote:
> On 31.12.2025 00:05, Matthieu Longo wrote:
>> --- a/binutils/testsuite/lib/binutils-common.exp
>> +++ b/binutils/testsuite/lib/binutils-common.exp
>> @@ -507,6 +507,36 @@ proc gas_sframe_check {} {
>>       return $check_as_sframe_result
>>   }
>>   
>> +# Whether a target support Object Attributes v1
>> +proc supports_oa_v1 {} {
>> +    if { ! [is_elf_format] } {
>> +	return 0
>> +    }
>> +    if { [istarget arc-*-*]
>> +	 || [istarget arm*-*-*]
>> +	 || [istarget csky*-*-*]
>> +	 || [istarget loongarch*-*-*]
>> +	 || [istarget m68*-*-*]
>> +	 || [istarget mips*-*-*]
>> +	 || [istarget msp*-*-*]
>> +	 || [istarget powerpc*-*-*]
>> +	 || [istarget riscv*-*-*]
>> +	 || [istarget s390*-*-*]
>> +	 || [istarget sparc*-*-*]
>> +	 || [istarget tic6x*-*-*] } {
>> +	return 1
>> +    }
>> +    return 0
>> +}
>> +
>> +# Whether a target support Object Attributes v2
>> +proc supports_oa_v2 {} {
>> +    if { [is_elf_format] && [istarget aarch64*-*-*] } {
> 
> Can this please be split right away like you have now done in
> supports_oa_v1?
> 
> Also, nit: In the comment both here and above, it wants to be "supports".
> 

Fixed.

>> +	return 1
>> +    }
>> +    return 0
>> +}
> 
> More generally: Rather than re-enumerating all relevant targets in both
> of these helpers, we can't e.g. probe gas? I wonder what would happen if
> some tc-*.h defined TC_OBJ_ATTR_v{1,2} dependent upon particular TE_*
> settings. Afaict the enumerations here would then need to become yet
> more complex.
> 

The only test that comes to my mind when testing support for OAvX, consists in trying to compile a file containing the directives, and if it fails, then OAvX is not supported, otherwise it is.
Such a test used to enable/disable tests is doing the same thing as the test itself, so it seems redundant to me.
With the current approach, if someone adds or removes support of OAvX on an architecture, one will at least detect it quickly via a test failure, and will have to modify the list of targets to make the tests pass.

>> --- /dev/null
>> +++ b/gas/testsuite/gas/gnu-attributes/oa-gnu-attribute-directive.d
>> @@ -0,0 +1,4 @@
>> +# name: GNU attributes v1/v2: no support for directive .gnu_attribute
>> +# notarget: [supports_oa_v1] [supports_oa_v2]
>> +# error: \A[^\n]+: Assembler messages:
>> +# error: \n[^\n]+: Error: unknown pseudo-op: `\.gnu_attribute'\Z
>> --- /dev/null
>> +++ b/gas/testsuite/gas/gnu-attributes/oa-gnu-attribute-directive.s
>> @@ -0,0 +1 @@
>> +	.gnu_attribute  0, 1
>> --- /dev/null
>> +++ b/gas/testsuite/gas/gnu-attributes/oa-gnu-subsection-directive.d
>> @@ -0,0 +1,4 @@
>> +# name: GNU attributes v2: no support for directive .gnu_subsection
>> +# notarget: [supports_oa_v2]
>> +# error: \A[^\n]+: Assembler messages:
>> +# error: \n[^\n]+: Error: unknown pseudo-op: `\.gnu_subsection'\Z
>> --- /dev/null
>> +++ b/gas/testsuite/gas/gnu-attributes/oa-gnu-subsection-directive.s
>> @@ -0,0 +1 @@
>> +	.gnu_subsection gnu_foo_1, optional, ULEB128
> 
> For all of the above I consider the file names misleading: These don't test
> the directives, but they test that the directives are invalid / unrecognized.
> 

What about renaming them to oa-no-gnu-attribute-directive.(d|s) and oa-no-gnu-subsection-directive.(d|s) ?

>> --- /dev/null
>> +++ b/gas/testsuite/gas/gnu-attributes/oav2-failures-1.l
>> @@ -0,0 +1,44 @@
>> +.*: Assembler messages:
>> +.*: Error: declaration of an attribute outside the scope of an attribute subsection
>> +.*: Error: attribute 1 cannot be redefined
>> +.*: Error: unexpected value -1, expected `unsigned integer' instead
>> +.*: Error: could not parse attribute tag
>> +.*: Error: unknown identifier 'Tag_Unknown' in this context
>> +.*: Error: could not parse attribute tag
>> +.*: Error: unknown identifier 'Tag_Unknown' in this context
>> +.*: Error: could not parse attribute tag
>> +.*: Error: unexpected `string' "plop", expected `unsigned integer' instead
>> +.*: Error: could not parse attribute value
>> +.*: Error: unexpected value -1, expected `unsigned integer' instead
>> +.*: Error: could not parse attribute value
>> +.*: Error: unexpected `string' "foo", expected `unsigned integer' instead
>> +.*: Error: could not parse attribute value
>> +.*: Error: unexpected integer 1, expected `string' instead
>> +.*: Error: could not parse attribute value
>> +.*: Error: attribute 4 cannot be redefined
>> +.*: Error: comprehension and encoding of a subsection cannot be omitted on the first declaration
>> +.*: Error: incompatible redeclaration of subsection vendor_1_subsection_3
>> +.*:  Info: previous declaration had properties: comprehension=required, encoding=NTBS
>> +.*: Error: incompatible redeclaration of subsection vendor_1_subsection_3
>> +.*:  Info: previous declaration had properties: comprehension=required, encoding=NTBS
>> +.*: Error: incompatible redeclaration of subsection vendor_1_subsection_3
>> +.*:  Info: previous declaration had properties: comprehension=required, encoding=NTBS
>> +.*: Error: unknown identifier 'ntbs' in this context
>> +.*: Error: unknown identifier 'uleb128' in this context
>> +.*: Error: expression '.vendor' does not resolve to an integer literal
>> +.*: Error: fell back to integer literal extraction from expression, but expected `identifier' instead
>> +.*: Error: expected <subsection_name>, <comprehension>, <encoding>
>> +.*: Error: unknown identifier 'uleb128' in this context
>> +.*: Error: unknown identifier 'optial' in this context
>> +.*: Error: unknown identifier 'ul128' in this context
>> +.*: Error: invalid value 2, expected values for <comprehension> are 0 \(=`required'\) or 1 \(=`optional'\)
>> +.*: Error: invalid value 2, expected values for <encoding> are 0 \(=`ULEB128'\) or 1 \(=`NTBS'\)
>> +.*: Error: unexpected comma before parameter 2
>> +.*: Error: junk at end of line, first unrecognized character is `,'
>> +.*: Error: unexpected comma before parameter 1
>> +.*: Error: missing comma after parameter 2
>> +.*: Error: unexpected comma before parameter 2
>> +.*: Error: junk at end of line, first unrecognized character is `,'
>> +.*: Error: unexpected comma before parameter 1
>> +.*: Error: junk at end of line, first unrecognized character is `1'
>> +.*: Error: attribute 1 cannot be redefined
> 
> Repeating a question already raised on v10: Is the exact wording really relevant
> in every one of the cases? My suggestion to split off some parts into info
> diagnostics was in part to then possibly have the respective expectation perhaps
> as short as
> 
> .*:  Info: .*
> 
> i.e. merely demanding that there is some further explanatory info.
> 

Fixed.

> Another example would be
> 
> .*: Error: invalid value 2, expected values for <comprehension> are .*
> 

Fixed.

> Further many of the "junk at end of line" look to be secondary errors. Ideally
> these would be avoided altogether (as a rule of thumb there should be just one
> diagnostic per statement; see a respective comment I mad on an earlier patch),
> but if that's not feasible for some reason, then their presence is entirely
> irrelevant in this test, I would say.
>

Each of those "junk at end of line" and "unexpected/missing comma" errors corresponds to one assembly line, and are not multiple errors generated on the same line.
The details seem relevant to me, as they make clear for the person reading the assembly what error is expected.

Matthieu