PR28977 tc-i386.c internal error in parse_register

[Jan Beulich]

On 18.03.2022 08:32, Alan Modra wrote:
> On Fri, Mar 18, 2022 at 08:12:46AM +0100, Jan Beulich wrote:
>> On 18.03.2022 07:56, Alan Modra via Binutils wrote:
>>> 	PR 28977
>>> 	* config/tc-i386.c (parse_register): Handle X_op not O_register
>>> 	as for a non-reg_section symbol.  Simplify array bounds check.
>>
>> Hmm, isn't it that ...
>>
>>> --- a/gas/config/tc-i386.c
>>> +++ b/gas/config/tc-i386.c
>>> @@ -12952,17 +12952,18 @@ parse_register (char *reg_string, char **end_op)
>>>  	{
>>
>> ... the if() right outside of context here is pointing at the actual
>> problem? Why would "s=%rdx % %rcx" result in a reg_section expression?
>> Imo this clearly ought to be expr_section.
> 
> Perhaps, but we are off in the weeds anyway.
> 
> The original fuzzer input had a completely crazy expression for "s".
> s=%ymm5%%%!%%%%!%%%%%%%
%%%%%%%%%%%%%%��������������������������%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%!%ebp%%%%%%%%%%%%%%%%%%M%%%%%%[s<��%[s<�����%%%%%��������������/+�������������%%%%[s<��%[s<�����%%%%'%%%%%%%%%%%%%%%%;%%%%%%!%%%%!%%%%%%%%%%%%%#NO
> 
> My testcase was a little tidier but still gives:
> 
> mad.s: Error: invalid operands (*GAS `reg' section* and *GAS `reg' section* sections) for `%' when setting `s'

That's only with your change in place, I assume? I'm not seeing
this with your change not in place (i.e. on a slightly older
tree I'm working with).

> The aim of the patch is to stop an abort *before* we decide the
> expression is invalid.  i386 parse_register was being called via
> md_parse_name in gas/expr.c:operand.

It still feels like your change is merely hiding a problem elsewhere.
Going from your example (and observing where the abort actually is
reported) I added a 3rd instance of x=s. Then the abort continues to
be reported on the 2nd instance. If things were working consistently,
I would expect it to happen either on the first instance or at the
end of the file (in this latter case the location reported would
simply be bogus).

I think the original know(e->X_op == O_register) was actually quite
appropriate when seeing a reg_section symbol come in. No reg_section
symbols violating this should ever be constructed, at least not for
x86. There might be architectures where such makes sense, albeit
code like this in expr.c:

	  else if (mode != expr_defer && segment == reg_section)
	    {
	      expressionP->X_op = O_register;
	      expressionP->X_add_number = S_GET_VALUE (symbolP);
	    }

makes me think such should never be put into existence. I seem to
have a vague recollection of, very long ago, having discussed with
you already the question of too little use of expr_section in the
course of expression evaluation (without any actual outcome as far
as changes to the code).

Jan