Re: [PATCH] gas/RISC-V: adjust assembler for opcode table re-ordering

[Jan Beulich <jbeulich@suse.com>]

On 09.01.2023 22:59, Maciej W. Rozycki wrote:
> On Mon, 9 Jan 2023, Palmer Dabbelt wrote:
> 
>>>>> The similar workaround in my_getSmallExpression() actually looks
>>>>> suspicious to me: I expect that it would get in the way of using equates
>>>>> "shadowing" names of GPRs.
>>>>>
>>>>> --- a/gas/config/tc-riscv.c
>>>>> +++ b/gas/config/tc-riscv.c
>>>>> @@ -3266,6 +3266,17 @@ riscv_ip (char *str, struct riscv_cl_ins
>>>>>  	      continue;
>>>>>
>>>>>  	    case 'a': /* 20-bit PC-relative offset.  */
>>>>> +	      /* Like in my_getSmallExpression() we need to avoid emitting
>>>>> +		 a stray undefined symbol if the 1st JAL entry doesn't match,
>>>>> +		 but the 2nd (with 2 operands) might.  */
>>>>> +	      if (oparg == insn->args)
>>>>> +		{
>>>>> +		  asargStart = asarg;
>>>>> +		  if (reg_lookup (&asarg, RCLASS_GPR, NULL)
>>>>> +		      && (*asarg == ',' || (ISSPACE (*asarg) && asarg[1] ==
>>>>> ',')))
>>>>> +		    break;
>>>>> +		  asarg = asargStart;
>>>>> +		}
>>>>>  	    jump:
>>>>>  	      my_getExpression (imm_expr, asarg);
>>>>>  	      asarg = expr_end;
>>>>
>>>> Thanks for the patch. I have tested it and confirmed it fix the problem
>>>> I reported.
>>>
>>> With 2.40 scheduled to be cut in less than a week, may I ask for an arch
>>> maintainer's view here?
>>
>> Thanks for fixing this.  I don't have any issues with what's there, but looks
>> like I'm also getting some failures (glibc/multilib errno related stuff).  I'm
>> trying to bisect those so I can't really get a proper test up now, I'll try to
>> do so ASAP as it's really late to have stuff broken.
> 
>  I wonder why the RISC-V port needs such a hack while the MIPS one 
> doesn't.

Perhaps I misunderstood your earlier reply then. There you said you deal with
this by carefully ordering the opcode table. Here restoring the original order
would only be a temporary workaround, as it would re-introduce the
disassembler issue that was fixed by altering the order: Alias entries need to
come ahead of "real" ones, or else respective alias mnemonics would never be
emitted by the disassembler. Hence a solution is needed here which retains the
order, and which also respects that insn operands may be parsed
- more than once,
- with identical names having different meaning depending on context.
I realize what I'm doing is a hack, but I cannot think of anything better.

Jan