How to update RISCV-64 disassembly for extensions?

[thixotropist]

I'm planning on starting some PRs to improve RISCV-64 disassembly of instructions added as recent extensions. Has anyone suggestions or guidance on how to best approach this?

The biggest current problem is in Ghidra's handling of RISCV-64 vector extensions. Half of the vector instructions handled by binutils-2.41 are unimplemented in Ghidra 10.4.DEV, and many of those that are implemented disassemble incorrectly for the stable vector extension release.

The baseline approach is simple:

• adapt binutils as the reference - Ghidra should be able to disassemble RISCV-64 object files assembled from the binutils-gdb/gas/testsuite/gas/riscv. The Ghidra disassembly window should look a lot like what objdump -d generates from the exemplar object files.
• prioritize extensions present in the RISCV RVA23 profile or found in publicly released RISCV disk images. So hypervisor and vector extensions come first, with complex vendor-specific https://github.com/T-head-Semi extensions deferred. Crypto and bit-manipulation instructions would be in the middle.
• ignore RISCV-32 for now
• ignore ML extensions for now

There are a bunch of design questions this approach raises, questions I hope this community can comment on:

1. Is it better to have a series of small PRs or a few bigger ones?
2. Are there any lessons-learned from adding x86_64 vector instructions to Ghidra? For example, what to do now to make pcode generation and decompilation easier in the future?
3. There are usually several instruction formats the binutils gas assembler will translate into a given instruction. objdump will select just one of these for the disassembly. Should Ghidra match objdump or provide the simplest compatible source?
4. Some instruction operands can be better rendered as enum constants - are these supported in sleigh files? For example, in fence instructions an 0xf operand is best rendered as something like 'iorw'.
5. Any lessons learned from Xtensa for handling easily customized instruction set architectures? The binutils gas assembler essentially lets you change the extension set ( Ghidra 'language') at each compilation unit.
6. How to acknowledge and track (but maybe defer) vendor-specific RISCV extensions. like Alibaba's T-Head extensions?

I expect to add some test harness code to https://github.com/thixotropist/ghidra_import_tests later this week, showing some of the current divergences between Ghidra and objdump.

[thixotropist]

The PR updating RISCV64 vector extensions should be ready by the end of the week. I'll bundle a proposed acceptance test in with the PR, essentially:

• import and assemble the binutils RISVC64 vector extension test suite as the reference set vector.o, using a September snapshot of the binutils gas assembler.
• disassemble the reference set vector.o using the snapshot objdump to the ascii listing reference.objdump
• import vector.o into ghidra 10.dev, disassemble, and export to vector.o.txt as ASCII with mnemonic size 20
• postprocess reference.objdump and vector.o.txt to remove formatting differences
• compare the Ghidra and objdump disassembly using meld or a similar visual diff tool

Note that this implicitly adopts several design elements from binutils:

• If binutils feels a RISCV-64 extension is ready for inclusion in gas, objdump, and the gas integration testsuite, then it is ready for Ghidra consideration.
• Tracking the semantics of vector instructions is hard on humans. The disassembly should make that a little easier, where possible. For example, masked and unmasked instructions should be displayed differently, with unmasked instructions showing nothing in the vm mask field and masked instructions showing the explicit mask register source v0.t .

None of these vector extension instructions generate pcode or provide further semantics for the decompiler. Issue #5769 raises some good points concerning pcode extensions for capturing memmov behavior. The RISCV-64 vector instruction provides a different approach to memmov, then goes on to implement many much more complex operations. GCC-14 intrinsics may give us some good examples on what to look for in SIMD pcode semantics. The development tip of libssl source code might also be worth looking into.