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

[Matthieu Longo]

On 15/01/2026 08:39, Jan Beulich wrote:
> 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).
> 

Fixed.

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

This last error is emitted because the junks at the end of line didn't prevent the parsing of the attribute from succeeding.
So then we try to record the parsed attribute. This is when the second error is raised.
This behavior seems acceptable, given that a first error in the file could trigger a whole new set of errors that don't necessarily make a lot of sense.
Please let me know if you disagree.

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

This is a good compromise.
Fixed.

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

What about this output ? Would it be less confusing ?

.*: Error: syntax error, comma not expected here
.*: Error: junk at end of line, first unrecognized character is `,'
.*: Error: syntax error, comma not expected here
.*: Error: syntax error, comma missing here
.*: Error: syntax error, comma not expected here
.*: Error: junk at end of line, first unrecognized character is `,'
.*: Error: syntax error, comma not expected here
.*: Error: junk at end of line, first unrecognized character is `1'
.*: Error: attribute '1' cannot be redefined

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

Matthieu