[PATCH] RISC-V: don't disassemble unrecognized insns as .byte

[Nelson Chu]

Hi Maciej,

On Mon, Jan 30, 2023 at 9:51 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Mon, 30 Jan 2023, Nelson Chu wrote:
>
> > > Insn width granularity being 16 bits, produce 16 bits of data per output
> > > element for the non-special-cased insn widths. Besides being slightly
> > > more natural (in particular having the first element carry everything
> > > that's needed for determining insn length), this is also slightly more
> > > compact.
> >
> > Sounds reasonable and good, so please commit, thanks.
>
>  Why not `.short' though, the more usual pseudo-op (and documented as
> portable in the GAS manual)?

Not sure if there are any documents mentioning this, but I remember
that there has always been an issue of hoping to distinguish whether
the encodings is an instruction or data  The .<N>byte may not be used
to do that at the beginning (maybe just let dis-assembler dump the
legal formats, https://github.com/bminor/binutils-gdb/commit/6a7f57668afcd841e8fc6b507a27bb20e9209fa9),
but sometimes it has the same effect - For example, .2byte is an
instruction but unrecognized, .short is a data in text.  However, it
isn't good enough, since,

% cat tmp.s
.text
.short 0x1
.insn 0x1
.2byte 0x1
% riscv64-unknown-elf-as tmp.s -o tmp.o
% riscv64-unknown-elf-objdump -d tmp.o
...
Disassembly of section .text:

0000000000000000 <.text>:
   0: 0001                .short 0x0001
   2: 0001                .2byte 0x1
   4: 0001                .short 0x0001
...

The .<N>byte in assembly will also be treated as data to dump, so
ideally, dump these unrecognized instructions as .insn is probably
more reasonable and won't be confused.

Thanks
Nelson