[PATCH v9 04/19] gas: implement parsing of object attributes v2

[Jan Beulich]

On 04.11.2025 18:32, Matthieu Longo wrote:
> On 24/10/2025 15:19, Jan Beulich wrote:
>> On 01.09.2025 18:56, Matthieu Longo wrote:
>>> +
>>> +/* Return true if the next characters are suspected to represent an integer
>>> +   literal.  */
>>> +static bool
>>> +look_like_integer_literal (const char *cursor)
>>> +{
>>> +  if (ISDIGIT (*cursor))
>>> +    return true;
>>> +  if (! (*cursor == '+' || *cursor == '-' || *cursor == '~'))
>>> +    return false;
>>> +  ++cursor;
>>> +  while (ISSPACE (*cursor))
>>> +    ++cursor;
>>> +  return ISDIGIT (*cursor);
>>> +}
>>
>> Hmm, now that I look at the result, maybe I misled you. An "integer literal"
>> would perhaps indeed not allow for ~ and also not for a blank between sign
>> and first digit. Yet then, as before, I'm having trouble seeing why proper
>> expressions (involving perhaps more than just integer literals, e.g. also
>> parentheses) shouldn't be acceptable.
> 
> I decided to remove this function, and change the implementation of 
> obj_attr_parse_arg(). Please have a look at it and let me know if you 
> think that it looks better.
> 
> Please keep in mind that I try not to reinvent the wheel and not to do 
> open coding, but the existing parsing utilities in binutils are not very 
> helpful for what I try to achieve.
> 
> Here are the major changes compare to the previous implementation:
> - move the erroring back into obj_attr_parse_arg () as much as possible.
> - better detection of the expected type VS the found type.
> - improvement of the error messages.
> - move most of the calls to ignore_rest_of_line(), when a error is met, 
> into vendor_attribute_parse_args() and vendor_subsection_parse_args().

I'm sorry, but looking at an incremental diff isn't really helpful here.
This being new code (when taking the series as a whole), it would be much
easier to look at the newly introduced code in its entirety.

> It is a pity that binutils does not have a recursive parser that would 
> return tokens, it would really make things easier and would avoid this 
> open-coding.
> Is the absence of such a parser due to the legacy parsing scattered 
> everywhere ?

Likely; I don't know all of the history.

> and the code change would be too disruptive ?

Hard to tell. As I have learned the hard way [1], parsing is pretty
delicate. With that attempt having failed (I really should find time to
make a 2nd try), I find it hard to imagine that parsing into a stream of
tokens would fare overly well.

Jan

[1] https://sourceware.org/pipermail/binutils/2024-July/136053.html