RISC-V: Support for vendor extensions

[gamelaster]

Many chips currently use T-Head cores (C906, E907, C910 etc.), whose contains custom RISC-V ISA extensions.
In this particular case, T-Head published it's specs here.

I would like to ask, what is recommended and best way of adding support for those instructions into Ghidra?
@florolf (I hope you don't mind the ping!) made support for some of them via hacky solution, directly modifying .sinc files (the changes are here), although I am not sure if this would be possible to get into upstream, without better support of vendor extensions in Ghidra.

Thanks

[mumbel]

This is not the way to go about it. Creating a new sinc file with the extension and then including it in the right order. In this case, include it before riscv.custom.sinc is included would be the best generic way. Possibly mix in context register logic and ifdefs.

The straight forward way would likely be a new T-Head slaspec file and include all the other sinc and vendor extension sinc files. If the riscv.custom.sinc is entirely unused it could be omitted that from that slaspec. Then add a new entry in the ldefs that is T-Head.

[madushan1000]

thank you for the information :) , I will take a deeper look into adding custom sinc files

[madushan1000]

@thixotropist btw if you're going to add t-head instructions to you pr, some of these instructions are already implemented in the ghidra fork mentioned above (https://github.com/florolf/ghidra/commits/t-head)

[thixotropist]

Thanks! The fork you mentioned does a nice job of handling the pcode. I'll add something similar into my work.

[thixotropist]

I've added THead RISCV vendor extensions to PR #5778. Comments and corrections are appreciated.

Notes:

• Ghidra disassembly testing uses binutil-2.41 gas testsuite files as source input and the associated assembler and objdump toolchain to generate reference disassembly.
• Generated Ghidra pcode has not been tested and likely contains errors, especially where zero- and sign-extension is called for.

[madushan1000]

I just gave it a try, I don't see anything obviously broken compared to the fork I mentioned, at least in my projects. In fact, de-compiler output is much better in some cases.