[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