Re: [PATCH 2/2] RISC-V: Better support for long instructions

[Tsukasa OI <research_trasio@irq.a4lg.com>]

c.f. PATCH v2 2/2
<https://sourceware.org/pipermail/binutils/2022-November/124598.html>

On 2022/11/21 16:37, Jan Beulich wrote:
> On 19.11.2022 08:10, Tsukasa OI wrote:
>> From: Tsukasa OI <research_trasio@irq.a4lg.com>
>>
>> Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
>> instructions with .insn") tried to start supporting long instructions but
>> it was insufficient.
>>
>> 1.  It heavily depended on the bignum internals (radix of 2^16),
>> 2.  It generates "value conflicts with instruction length" even if a big
>>     number instruction encoding does not exceed its expected length,
>> 3.  Because long opcode was handled separately (from struct riscv_cl_insn),
>>     some information like DWARF line number correspondence was missing and
>> 4.  On the disassembler, disassembler dump was limited up to 64-bit.
>>     For long (unknown) instructions, instruction bits are incorrectly
>>     zeroed out.
> 
> Just FTR - of these 1 and 4 were deliberate (as in: deemed acceptable), the
> former the keep the code reasonably simple and the latter because focus was
> solely on the assembler.

I thought it's possible that 1 was a deliberate choice.  I don't want to
depend on some internal structure that could change easily (as long as
this is a reasonable choice).  To be honest, I didn't like my
"extracting prefix of an instruction" logic in PATCH v1 but I found a
good function: generic_bignum_to_int32 and decided use it on PATCH v2
(as a result, PATCH v2 2/2 is a bit simpler than PATCH v1).

For 4, resolving from the start would be better but since my current
focus is the RISC-V disassembler, I'm happy to resolve it (fortunately,
it didn't require large changes).

Nelson assigned you as the person who makes the final judgement for this
series and I want to hear your thoughts/decision about PATCH v2 2/2.

Thanks,
Tsukasa

> 
> I recall dealing with some instances of 2, but as you demonstrate I failed
> to recognize and deal with further cases.
> 
> I will admit that I didn't even think of debug info generation.
> 
>> To solve these problems, this commit:
>>
>> 1.  Handles bignum (and its encodings) precisely,
>> 2.  Incorporates long opcode handling into regular struct
>>     riscv_cl_insn-handling functions.
>> 3.  Adds packet argument to support dumping instructions
>>     longer than 64-bits.
> 
> Thanks for taking the time to make improvements there.
> 
> Jan
>