public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: Nelson Chu <nelson@rivosinc.com>, Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] RISC-V: Dump instruction without checking architecture support as usual.
Date: Fri, 27 Oct 2023 11:17:29 +0900	[thread overview]
Message-ID: <801ccf05-3ab8-4b3d-b6b6-4bd8edd2ec67@irq.a4lg.com> (raw)
In-Reply-To: <20231027003917.67308-1-nelson@rivosinc.com>

On 2023/10/27 9:39, Nelson Chu wrote:
> Since QEMU have supported -Max option to to enable all normal extensions,
> the dis-assembler should also add an option, -M,max to do the same thing.
> For the instruction, which have overlapped encodings like zfinx, will not
> be considered by the -M,max option.
> 
> opcodes/
> 	* riscv-dis.c (all_ext): New static boolean.  If set, disassemble
> 	without checking architectire string.
> 	(riscv_disassemble_insn): Likewise.
> 	(parse_riscv_dis_option_without_args): Recognized -M,max option.
> ---
>  opcodes/riscv-dis.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

LGTM.

For overlapped encodings, riscv_opcodes ordering will get more important
but I don't think this change will "break" anything ("max" should be
used only when the specific architecture IS NOT important).

I remember I submitted a proposal (long time ago) to add a disassembler
option to specify custom ISA string for the disassembler (where specific
architecture IS important) and it might be the time to rework on this
(because "max" and my past proposal "arch=ARCH" would work as a pair).

Tsukasa


p.s.

Also looking at your patch, I started to think disassembler options that
would visualize custom instructions (or custom instruction/CSR space)
might be helpful for some reverse engineering needs (the priority is
low, even for me though).

  reply	other threads:[~2023-10-27  2:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-27  0:39 Nelson Chu
2023-10-27  2:17 ` Tsukasa OI [this message]
2023-10-27  2:55   ` Nelson Chu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=801ccf05-3ab8-4b3d-b6b6-4bd8edd2ec67@irq.a4lg.com \
    --to=research_trasio@irq.a4lg.com \
    --cc=binutils@sourceware.org \
    --cc=nelson@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).