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

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

[Jan Beulich]

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.
---
I think output would be even more neat if .<N>byte were suppressed when
generic code already prints the raw insn (or maybe something like
<unknown> was printed instead).

As to the special case code for 2-, 4-, and 8-byte insns: Any thoughts
towards zero-padding the numbers there as well? That would make yet more
noticable what the insn width is; in particular - see e.g. ".8byte 0x3f"
in full disassembly of the testcases modified here - it would avoid the
value looking like it was for a more narrow one.

Taking it yet one step further - how about printing unknown insns as
".insn ...", matching what gas would consume?

--- a/gas/testsuite/gas/riscv/insn-na.d
+++ b/gas/testsuite/gas/riscv/insn-na.d
@@ -76,11 +76,11 @@ Disassembly of section .text:
 [^:]+:[ 	]+007f 0000 0000 0000 0000[ 	]+[._a-z].*
 [^:]+:[ 	]+0000107f 00000000 00000000[ 	]+[._a-z].*
 [^:]+:[ 	]+607f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000[ 	]+[._a-z].*
-[^:]+:[ 	]+007f 0000 0000 0000 8000[ 	]+\.byte[ 	]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
-[^:]+:[ 	]+007f 0000 0000 0000 8000[ 	]+\.byte[ 	]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
-[^:]+:[ 	]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[ 	]+\.byte[ 	]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-[^:]+:[ 	]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[ 	]+\.byte[ 	]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
-[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
-[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
-[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
+[^:]+:[ 	]+007f 0000 0000 0000 8000[ 	]+\.2byte[ 	]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
+[^:]+:[ 	]+007f 0000 0000 0000 8000[ 	]+\.2byte[ 	]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
+[^:]+:[ 	]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[ 	]+\.2byte[ 	]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
+[^:]+:[ 	]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[ 	]+\.2byte[ 	]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
+[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
+[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
+[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
+[^:]+:[ 	]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
--- a/gas/testsuite/gas/riscv/insn.d
+++ b/gas/testsuite/gas/riscv/insn.d
@@ -95,25 +95,25 @@ Disassembly of section .text:
 [^:]+:[ 	]+607f 0000 0000 0000[ 	]+[._a-z].*
 [^:]+:[ 	]+0000 0000 0000 0000 ?
 [^:]+:[ 	]+0000 0000 0000 ?
-[^:]+:[ 	]+007f 0000 0000 0000[ 	]+\.byte[ 	]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
+[^:]+:[ 	]+007f 0000 0000 0000[ 	]+\.2byte[ 	]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
 [^:]+:[ 	]+8000 ?
-[^:]+:[ 	]+007f 0000 0000 0000[ 	]+\.byte[ 	]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
+[^:]+:[ 	]+007f 0000 0000 0000[ 	]+\.2byte[ 	]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
 [^:]+:[ 	]+8000 ?
-[^:]+:[ 	]+607f 89ab 4567 0123[ 	]+\.byte[ 	]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+[^:]+:[ 	]+607f 89ab 4567 0123[ 	]+\.2byte[ 	]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
 [^:]+:[ 	]+3210 7654 ba98 fedc ?
 [^:]+:[ 	]+0000 0000 0000 ?
-[^:]+:[ 	]+607f 89ab 4567 0123[ 	]+\.byte[ 	]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+[^:]+:[ 	]+607f 89ab 4567 0123[ 	]+\.2byte[ 	]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
 [^:]+:[ 	]+3210 7654 ba98 fedc ?
 [^:]+:[ 	]+0000 0000 0000 ?
-[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
+[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
 [^:]+:[ 	]+89ab 4567 0123 3210 ?
 [^:]+:[ 	]+7654 ba98 00dc ?
-[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
+[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
 [^:]+:[ 	]+89ab 4567 0123 3210 ?
 [^:]+:[ 	]+7654 ba98 00dc ?
-[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
+[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
 [^:]+:[ 	]+89ab 4567 0123 3210 ?
 [^:]+:[ 	]+7654 ba98 fedc ?
-[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.byte[ 	]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
+[^:]+:[ 	]+607f 33cc 55aa cdef[ 	]+\.2byte[ 	]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
 [^:]+:[ 	]+89ab 4567 0123 3210 ?
 [^:]+:[ 	]+7654 ba98 fedc ?
--- a/opcodes/riscv-dis.c
+++ b/opcodes/riscv-dis.c
@@ -800,16 +800,16 @@ riscv_disassemble_insn (bfd_vma memaddr,
       {
         int i;
 	(*info->fprintf_styled_func)
-	  (info->stream, dis_style_assembler_directive, ".byte");
+	  (info->stream, dis_style_assembler_directive, ".2byte");
 	(*info->fprintf_styled_func) (info->stream, dis_style_text, "\t");
-        for (i = 0; i < insnlen; ++i)
+        for (i = 0; i < insnlen; i += 2)
           {
             if (i > 0)
 	      (*info->fprintf_styled_func) (info->stream, dis_style_text,
 					    ", ");
+	    word = bfd_get_bits (packet + i, 16, false);
 	    (*info->fprintf_styled_func) (info->stream, dis_style_immediate,
-					  "0x%02x",
-					  (unsigned int) (*packet++));
+					  "0x%04x", (unsigned int) word);
           }
       }
       break;

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

[Nelson Chu]

On Fri, Jan 27, 2023 at 9:14 PM Jan Beulich <jbeulich@suse.com> 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.

> ---
> I think output would be even more neat if .<N>byte were suppressed when
> generic code already prints the raw insn (or maybe something like
> <unknown> was printed instead).
>
> As to the special case code for 2-, 4-, and 8-byte insns: Any thoughts
> towards zero-padding the numbers there as well? That would make yet more
> noticable what the insn width is; in particular - see e.g. ".8byte 0x3f"
> in full disassembly of the testcases modified here - it would avoid the
> value looking like it was for a more narrow one.
>
> Taking it yet one step further - how about printing unknown insns as
> ".insn ...", matching what gas would consume?

I don't remember how long ago, Kito did discuss this idea with me, but
since we haven't supported mapping symbols at that time, it's been
forgotten until this patch.  Anyway, I vote to dump the unrecognized
instructions into .insn directives, so if there is no objection,
please go ahead.

Also cc Kito, he should have almost forgotten about this :-)

Thanks
Nelson

>
> --- a/gas/testsuite/gas/riscv/insn-na.d
> +++ b/gas/testsuite/gas/riscv/insn-na.d
> @@ -76,11 +76,11 @@ Disassembly of section .text:
>  [^:]+:[        ]+007f 0000 0000 0000 0000[     ]+[._a-z].*
>  [^:]+:[        ]+0000107f 00000000 00000000[   ]+[._a-z].*
>  [^:]+:[        ]+607f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000[       ]+[._a-z].*
> -[^:]+:[        ]+007f 0000 0000 0000 8000[     ]+\.byte[       ]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
> -[^:]+:[        ]+007f 0000 0000 0000 8000[     ]+\.byte[       ]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
> -[^:]+:[        ]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[       ]+\.byte[       ]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> -[^:]+:[        ]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[       ]+\.byte[       ]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> -[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[       ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
> -[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[       ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
> -[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[       ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
> -[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[       ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
> +[^:]+:[        ]+007f 0000 0000 0000 8000[     ]+\.2byte[      ]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
> +[^:]+:[        ]+007f 0000 0000 0000 8000[     ]+\.2byte[      ]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
> +[^:]+:[        ]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[       ]+\.2byte[      ]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
> +[^:]+:[        ]+607f 89ab 4567 0123 3210 7654 ba98 fedc 0000 0000 0000[       ]+\.2byte[      ]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
> +[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[       ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
> +[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 00dc[       ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
> +[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[       ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
> +[^:]+:[        ]+607f 33cc 55aa cdef 89ab 4567 0123 3210 7654 ba98 fedc[       ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
> --- a/gas/testsuite/gas/riscv/insn.d
> +++ b/gas/testsuite/gas/riscv/insn.d
> @@ -95,25 +95,25 @@ Disassembly of section .text:
>  [^:]+:[        ]+607f 0000 0000 0000[  ]+[._a-z].*
>  [^:]+:[        ]+0000 0000 0000 0000 ?
>  [^:]+:[        ]+0000 0000 0000 ?
> -[^:]+:[        ]+007f 0000 0000 0000[  ]+\.byte[       ]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
> +[^:]+:[        ]+007f 0000 0000 0000[  ]+\.2byte[      ]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
>  [^:]+:[        ]+8000 ?
> -[^:]+:[        ]+007f 0000 0000 0000[  ]+\.byte[       ]+0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80
> +[^:]+:[        ]+007f 0000 0000 0000[  ]+\.2byte[      ]+0x007f, 0x0000, 0x0000, 0x0000, 0x8000
>  [^:]+:[        ]+8000 ?
> -[^:]+:[        ]+607f 89ab 4567 0123[  ]+\.byte[       ]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> +[^:]+:[        ]+607f 89ab 4567 0123[  ]+\.2byte[      ]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
>  [^:]+:[        ]+3210 7654 ba98 fedc ?
>  [^:]+:[        ]+0000 0000 0000 ?
> -[^:]+:[        ]+607f 89ab 4567 0123[  ]+\.byte[       ]+0x7f, 0x60, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> +[^:]+:[        ]+607f 89ab 4567 0123[  ]+\.2byte[      ]+0x607f, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc, 0x0000, 0x0000, 0x0000
>  [^:]+:[        ]+3210 7654 ba98 fedc ?
>  [^:]+:[        ]+0000 0000 0000 ?
> -[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
> +[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
>  [^:]+:[        ]+89ab 4567 0123 3210 ?
>  [^:]+:[        ]+7654 ba98 00dc ?
> -[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0x00
> +[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0x00dc
>  [^:]+:[        ]+89ab 4567 0123 3210 ?
>  [^:]+:[        ]+7654 ba98 00dc ?
> -[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
> +[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
>  [^:]+:[        ]+89ab 4567 0123 3210 ?
>  [^:]+:[        ]+7654 ba98 fedc ?
> -[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.byte[       ]+0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
> +[^:]+:[        ]+607f 33cc 55aa cdef[  ]+\.2byte[      ]+0x607f, 0x33cc, 0x55aa, 0xcdef, 0x89ab, 0x4567, 0x0123, 0x3210, 0x7654, 0xba98, 0xfedc
>  [^:]+:[        ]+89ab 4567 0123 3210 ?
>  [^:]+:[        ]+7654 ba98 fedc ?
> --- a/opcodes/riscv-dis.c
> +++ b/opcodes/riscv-dis.c
> @@ -800,16 +800,16 @@ riscv_disassemble_insn (bfd_vma memaddr,
>        {
>          int i;
>         (*info->fprintf_styled_func)
> -         (info->stream, dis_style_assembler_directive, ".byte");
> +         (info->stream, dis_style_assembler_directive, ".2byte");
>         (*info->fprintf_styled_func) (info->stream, dis_style_text, "\t");
> -        for (i = 0; i < insnlen; ++i)
> +        for (i = 0; i < insnlen; i += 2)
>            {
>              if (i > 0)
>               (*info->fprintf_styled_func) (info->stream, dis_style_text,
>                                             ", ");
> +           word = bfd_get_bits (packet + i, 16, false);
>             (*info->fprintf_styled_func) (info->stream, dis_style_immediate,
> -                                         "0x%02x",
> -                                         (unsigned int) (*packet++));
> +                                         "0x%04x", (unsigned int) word);
>            }
>        }
>        break;

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

[Maciej W. Rozycki]

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)?

  Maciej

Re: [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

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

[Maciej W. Rozycki]

Hi Nelson,

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

 I wasn't aware about the RISC-V `.insn' pseudo-op.  I think it will make 
a lot of sense to use it here then, so I'd be happier with either:

   2: 0001                .insn 0x0001

or:

   2: 0001                .insn 0x2, 0x1

and analogously for unrecognised instructions comprised of a higher number 
of parcels according to the opcode allocation, e.g.:

Disassembly of section .text:
0000000000000000 <foo> .insn	0x00000000001f

or:

Disassembly of section .text:
0000000000000000 <foo> .insn	0x6, 0x1f

(here in the `--prefix-addresses' format).  The single-argument format may 
by clearer to the casual eye at the cost of extra leading zeros with some 
encodings.

  Maciej

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

[Nelson Chu]

On Mon, Jan 30, 2023 at 11:33 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> Hi Nelson,
>
> > 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.
>
>  I wasn't aware about the RISC-V `.insn' pseudo-op.  I think it will make
> a lot of sense to use it here then, so I'd be happier with either:
>
>    2: 0001                .insn 0x0001
>
> or:
>
>    2: 0001                .insn 0x2, 0x1
>
> and analogously for unrecognised instructions comprised of a higher number
> of parcels according to the opcode allocation, e.g.:
>
> Disassembly of section .text:
> 0000000000000000 <foo> .insn    0x00000000001f
>
> or:
>
> Disassembly of section .text:
> 0000000000000000 <foo> .insn    0x6, 0x1f
>
> (here in the `--prefix-addresses' format).  The single-argument format may
> by clearer to the casual eye at the cost of extra leading zeros with some
> encodings.

Yeah, dump these unrecognized instructions into the .insn directives
with the <bytes> field looks better.  Thanks for pointing this out :-)

Nelson

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

[Kito Cheng]

> > As to the special case code for 2-, 4-, and 8-byte insns: Any thoughts
> > towards zero-padding the numbers there as well? That would make yet more
> > noticable what the insn width is; in particular - see e.g. ".8byte 0x3f"
> > in full disassembly of the testcases modified here - it would avoid the
> > value looking like it was for a more narrow one.
> >
> > Taking it yet one step further - how about printing unknown insns as
> > ".insn ...", matching what gas would consume?
>
> I don't remember how long ago, Kito did discuss this idea with me, but
> since we haven't supported mapping symbols at that time, it's been
> forgotten until this patch.  Anyway, I vote to dump the unrecognized
> instructions into .insn directives, so if there is no objection,
> please go ahead.
>
> Also cc Kito, he should have almost forgotten about this :-)

I like printing .insn too, we have mapping symbols now, so it should
be able to distinguish between code and data :)

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

[Jan Beulich]

On 30.01.2023 02:40, Nelson Chu wrote:
> On Fri, Jan 27, 2023 at 9:14 PM Jan Beulich <jbeulich@suse.com> 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.

Given ...

>> ---
>> I think output would be even more neat if .<N>byte were suppressed when
>> generic code already prints the raw insn (or maybe something like
>> <unknown> was printed instead).
>>
>> As to the special case code for 2-, 4-, and 8-byte insns: Any thoughts
>> towards zero-padding the numbers there as well? That would make yet more
>> noticable what the insn width is; in particular - see e.g. ".8byte 0x3f"
>> in full disassembly of the testcases modified here - it would avoid the
>> value looking like it was for a more narrow one.
>>
>> Taking it yet one step further - how about printing unknown insns as
>> ".insn ...", matching what gas would consume?
> 
> I don't remember how long ago, Kito did discuss this idea with me, but
> since we haven't supported mapping symbols at that time, it's been
> forgotten until this patch.  Anyway, I vote to dump the unrecognized
> instructions into .insn directives, so if there is no objection,
> please go ahead.
> 
> Also cc Kito, he should have almost forgotten about this :-)

both of you think this is a good direction to follow, I won't even bother
committing the patch here, but make one to switch to emitting .insn right
away. With some luck later this week ...

Jan