RISC-V: mapping symbols vs "unimpl"

[Jan Beulich <jbeulich@suse.com>]

Nelson,

with your introduction of mapping symbols I have trouble expressing
certain spec-conforming deliberately illegal 32-bit instructions (low
16 bits all zero). I can't use "unimpl" itself, as that for whichever
reason resolves to "csrrw x0, cycle, x0" (and oddly enough using that
form as input goes through without even a warning, but that's just a
side note). I also can't use .insn, as that places requirements on
the low two bits of the main opcode. And now I also can't use .word
anymore, as that will cause mapping symbols to be inserted, which
therefore - by a disassembler honoring the mapping symbols - won't
disassemble as an instruction anymore.

Do you have any suggestion how to encode a spec-conforming "unimpl",
which I want to be part of my own disassembler's test cases (in
particular the 0xffff0000 form)? Since the commit introducing the
mapping symbols refers to Arm, I'd like to point out that their .insn
equivalents allow to encode entirely arbitrary instruction forms. But
of course I understand that RISC-V's insn length encoding scheme is
somewhat in conflict with this.

Two further remarks: Even ".insn ci ..." cannot be used, not even for
forms with the high 16 bits not all set (which again the main opcode
restriction would get in the way of): Already just temporarily
enabling RVC causes the RVC bit to be set in the ELF header flags.
Yet with that bit set 0xffff0000 is actually a 16-bit insn 0x0000
followed by a wider insn with the low 16 bits all set. IOW this
conflicts with the spec's wording of "minimal length insn with the
low 16 bits all zero".

And then I'm puzzled by the main opcode restriction related error
being raised a whopping 6 times for ".insn i 0, 0, x0, x30, ~0",
and still twice instead of just once for ".insn ci 3, 7, x31, ~0".

Jan