From: Kito Cheng <kito.cheng@gmail.com>
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
Date: Mon, 30 Jan 2023 10:07:46 +0800 [thread overview]
Message-ID: <CA+yXCZCesgJjwYHLA0Wunyen45DWjyJNJjKoTV9PB9weMFWHeQ@mail.gmail.com> (raw)
In-Reply-To: <CAPpQWtBF+ND85kZ-pZRiYgrnJ95s1gXdgii-gzwsE20o8o_1nA@mail.gmail.com>
> > 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 :)
next prev parent reply other threads:[~2023-01-30 2:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 13:14 Jan Beulich
2023-01-30 1:40 ` Nelson Chu
2023-01-30 1:51 ` Maciej W. Rozycki
2023-01-30 3:03 ` Nelson Chu
2023-01-30 3:33 ` Maciej W. Rozycki
2023-01-31 1:51 ` Nelson Chu
2023-01-30 2:07 ` Kito Cheng [this message]
2023-01-30 7:51 ` Jan Beulich
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=CA+yXCZCesgJjwYHLA0Wunyen45DWjyJNJjKoTV9PB9weMFWHeQ@mail.gmail.com \
--to=kito.cheng@gmail.com \
--cc=andrew@sifive.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
--cc=jim.wilson.gcc@gmail.com \
--cc=kito.cheng@sifive.com \
--cc=nelson@rivosinc.com \
--cc=palmer@dabbelt.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).