PR28977 tc-i386.c internal error in parse_register

[Alan Modra]

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'

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.

-- 
Alan Modra
Australia Development Lab, IBM