RFR: 8285711: riscv: RVC: Support disassembler show-bytes option

[Thomas Stuefe]

On Wed, 27 Apr 2022 10:10:30 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> When RVC (under which instruction size could become 2-byte) is enabled currently, the disassembler 'show-bytes' output is not right, for `Assembler::instr_len` doesn't get adjusted.
> 
> Using `-XX:+UnlockExperimentalVMOptions -XX:+UseRVC -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:PrintAssemblyOptions=no-aliases,numeric,show-bytes -XX:+PrintAssembly`
> 
> Before: (wrong)
> 
> ...
> 0x000000401354f9bc: 9722 4107  | auipc  x5,0x7412                               ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>   0x000000401354f9c0: e780 4210  | jalr  x1,260(x5) # 0x000000401a961ac0
>   0x000000401354f9c4: 1571 06e0  | c.addi16sp  x2,-224
>   0x000000401354f9c6: 06e0 16e4  | c.sdsp  x1,0(x2)
>   0x000000401354f9c8: 16e4 1ae8  | c.sdsp  x5,8(x2)
>   0x000000401354f9ca: 1ae8 1eec  | c.sdsp  x6,16(x2)
>   0x000000401354f9cc: 1eec 22f0  | c.sdsp  x7,24(x2)
>   0x000000401354f9ce: 22f0 26f4  | c.sdsp  x8,32(x2)
>   0x000000401354f9d0: 26f4 2af8  | c.sdsp  x9,40(x2)
> ...
> 
> 
> After: (right)
> 
> 0x0000004013546c2c: 97a2 4107  | auipc  x5,0x741a                               ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>   0x0000004013546c30: e780 42b9  | jalr  x1,-1132(x5) # 0x000000401a9607c0
>   0x0000004013546c34: 1571    | c.addi16sp  x2,-224
>   0x0000004013546c36: 06e0    | c.sdsp  x1,0(x2)
>   0x0000004013546c38: 16e4    | c.sdsp  x5,8(x2)
>   0x0000004013546c3a: 1ae8    | c.sdsp  x6,16(x2)
>   0x0000004013546c3c: 1eec    | c.sdsp  x7,24(x2)
>   0x0000004013546c3e: 22f0    | c.sdsp  x8,32(x2)
>   0x0000004013546c40: 26f4    | c.sdsp  x9,40(x2)
> 
> 
> The [RISC-V ISA manual](https://github.com/riscv/riscv-isa-manual/blob/04cc07bccea63f6587371b6c75b228af3e5ebb02/src/intro.tex#L630-L635) reads, 
>> We have to fix the order in which instruction parcels are stored in memory, independent of memory system endianness, to ensure that **the length-encoding bits always appear first in halfword address order**. This allows the length of a variable-length instruction to be quickly determined by an instruction-fetch unit by examining only the first few bits of the first 16-bit instruction parcel.
> 
> Instructions are stored in little-endian order, and in that only the first 16-bit matters, we could just check if the lowest 2 bits of it to detect the instruction length. 
> (48-bit and 64-bit instructions are not supported yet in the current backend)
> (extracting an `is_compressed_instr`, for this might get used in the future)
> 
> Thanks,
> Xiaolin

Not a riscv expert, but looks good to me.

One question, this only works if the pointer points to the start of an instruction, right? So, it would not work if the pointer pointed to the second half word of a four byte instruction?

In other words, in riscv, is it possible to take an arbitrary half word address into code, and determine the start of the instruction, and possibly go back n instructions? e.g. when duming arbitrary pieces of code as hex?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8421