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

["Maciej W. Rozycki" <macro@orcam.me.uk>]

On Tue, 10 Jan 2023, Jan Beulich wrote:

> >> 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.

 Correct.  But why does it require such an intervention on the GAS side?

 AFAIK similarly to the MIPS port and like the disassembler GAS tries to 
match instructions in the order they appear in the opcode table, except 
that the disassembler matches by the opcode/mask, but GAS matches by the 
mnemonic/operands.  It is expected that a single-operand alias appears 
first so that the disassembler matches it first (unless `-M no-aliases'), 
but it is also expected not to match a two-operand assembly instruction, 
so that GAS proceeds to the next candidate opcode table entry.

 And it does appear to happen, because correct machine code is produced 
regardless of your hack, except for the spurious symbol produced.  So is 
it not the case that simply the state (interal relocations recorded) is 
not correctly reset on an unsuccessful operand match?  Why does it have to 
be special-cased just for the `a' operand type?

  Maciej