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

[Jan Beulich]

On 14.01.2026 17:50, Matthieu Longo wrote:
> On 09/01/2026 09:19, Jan Beulich wrote:
>> On 31.12.2025 00:05, Matthieu Longo wrote:
>>> --- /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) ?

Yes please (despite the names then getting yet longer).

>>> --- /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'\)

To reply to your response further down, I need to start here: These two
correspond to

	.gnu_subsection vendor_1_subsection_4, 2, 1
	.gnu_subsection vendor_1_subsection_4, 1, 2

afaict. Subsequent to it there are 2 sets of 4 directives in the source,
which would mean a total of 8 more error messages. Yet ...

>>> +.*: 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

... there are 9 here.

That's just one excess diagnostic (apparently from the last line in the
source), yes, but still. Yet I now realize what further confused me: There
are plain numbers in the last 11 lines above, but what they refer to
varies. In "parameter <n>" you mean the <n>th parameter, which is fine. In
"invalid value <n>" you mean user input, which may better be quoted to
express that. Much like you quote "optial" and "ul128" in the immediately
preceding diagnostics. Of course there's a possible counter argument:
Ideally what is quoted would be the original user input, not the the result
of expression evaluation. But I think going the middle route is sufficient
here.

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

But then why is it once "unexpected comma" and once "junk at end of line, first
unrecognized character is `,'"? An excess comma generally indicates a subsequent
(possibly empty) argument. Imo excess commas should yield "too many arguments".

Whether empty arguments really are to be considered an error is harder to tell:
Note how e.g. get_absolute_expression() treats <nothing> as 0. I don't consider
this to be the best of all possible behaviors, yet consistency throughout the
assembler is a relevant criteria to consider.

> The details seem relevant to me, as they make clear for the person reading the assembly what error is expected.

I agree; as indicated above there was a further aspect causing me to consider
the "multiple error messages" issue to be wider than it is.

Jan