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

[Matthieu Longo]

On 15/01/2026 15:24, Jan Beulich wrote:
> On 15.01.2026 15:18, Matthieu Longo wrote:
>> 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/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.
> 
> But why? The line had an error; nothing needs generating / recording for
> it.
> 

demand_empty_rest_of_line() does not return any error code if junk is found.
Consequently, the rest of the code cannot know if an error occurred.

>>>>> 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
> 
> Yes, this is a little better. Still I'm not overly happy with it, as it still
> doesn't work in terms of excess / missing arguments. Excess arguments are okay
> to be "junk at end of line". That, however, also covers excess commas, i.e.
> I'd expect the same "junk at end of line" wherever above has "comma not
> expected here". A missing comma is one of two things: Either there's something
> else there (again "junk at end of line"), or there's nothing there ("too few
> arguments).
> 
> Jan

Should I understand from your comment that the current result is acceptable even if not perfect ?
Thanks for clarifying.

Matthieu