From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=+E4Q=53=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34])
	by sourceware.org (Postfix) with ESMTP id 643833858D35
	for <binutils@sourceware.org>; Mon, 30 Jan 2023 03:33:56 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 643833858D35
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id 6B2D092009D; Mon, 30 Jan 2023 04:33:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id 64B5492009B;
	Mon, 30 Jan 2023 03:33:55 +0000 (GMT)
Date: Mon, 30 Jan 2023 03:33:55 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Nelson Chu <nelson@rivosinc.com>
cc: Jan Beulich <jbeulich@suse.com>, Binutils <binutils@sourceware.org>, 
    Palmer Dabbelt <palmer@dabbelt.com>, Andrew Waterman <andrew@sifive.com>, 
    Jim Wilson <jim.wilson.gcc@gmail.com>, Kito Cheng <kito.cheng@sifive.com>
Subject: Re: [PATCH] RISC-V: don't disassemble unrecognized insns as .byte
In-Reply-To: <CAPpQWtAj5xoczt_8YNAwHK4mYNBfrsDqCz7gncX=6YUtWpPHew@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2301300314540.55843@angie.orcam.me.uk>
References: <dc521fdd-1462-0a4e-6d8e-5fa3f35c82b5@suse.com> <CAPpQWtBF+ND85kZ-pZRiYgrnJ95s1gXdgii-gzwsE20o8o_1nA@mail.gmail.com> <alpine.DEB.2.21.2301300149070.55843@angie.orcam.me.uk> <CAPpQWtAj5xoczt_8YNAwHK4mYNBfrsDqCz7gncX=6YUtWpPHew@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-1163.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <binutils.sourceware.org>

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