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

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

On Wed, 11 Jan 2023, Jan Beulich wrote:

> >  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?
> 
> The parsing of an 'a' type operand involves expression(), a side effect of
> which is to insert a symbol table entry for symbols not otherwise
> recognized (and note how my_getSmallExpression() addresses the same issue
> by filtering out GPR names first [1]). Yes, in a way this is an
> "insufficient undoing" issue, just that undoing of that symbol table
> insertion would be quite hard and/or fragile (from all I can tell). And
> this is where the dual meaning of symbol names comes into play: This looks
> to be intentional, and hence we can't make use of md_parse_name() to
> suppress the symbol table insertion in the first place for symbols which
> (in other contexts) identify registers.

 Thank you for looking into it.  Indeed it looks to me like a problem with 
`expression' (or `expr' really) and the way the RISC-V assembly dialect 
defines register references (unlike the MIPS one which uses a `$' prefix).  

 At a glance it seems to me that the correct approach would be to define a 
"dry run" mode for `expr' and use it in the RISC-V backend to validate an 
operand in the first invocation without causing any side effects, and then 
only once all the operands have been processed and an opcode table entry 
accepted `expr' would be called to finalise the expression.

 I realise it's something you may not be willing to commit to, as it's 
likely a larger task than a random tweak to the RISC-V backend, but I 
think it's the way we ought to do it rather than piling up workarounds.

 FWIW,

  Maciej