New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RISC-V: Add WCH/QingKe XW extension #6390
base: master
Are you sure you want to change the base?
Conversation
One thing sticking out are the insn names conflicting with ratified Zcb instructions. Naming them like |
To fix build error:
|
If you can provide a binary exemplar or two including the new instructions, I'd like to add it to my RISCV collection. Metadata describing this RSA extension would be nice too, for instance:
Mostly I'm looking for hints on whether the vendor considers this extension tracked for standardization, deprecated in favor of newer extensions, or proprietary. |
re #6390 (comment): to be honest I have no idea what this actually does (running sleigh manually works without doing this), but I've added it as a separate commit re #6390 (comment): i am attaching the files that I used to visually smoke-test this PR (as well as the quick hack script that generated them): wch-xw.zip the opcodes are definitely found in the bootroms of the ch32v003/ch32v203/ch32v208 chips, but i do not want to be responsible for publicly distributing those. i've also been able to make vendor gcc emit them for ad-hoc specially-contrived test functions. the disassembly makes sense when skimming these cases. as to your questions:
|
Thanks for the exemplars and the contextual metadata. I'll see about getting them into my exemplars repo. The If anyone knows how to triage intellectual property rights and licensing from reverse-engineered binaries we could have a fun discussion here. I've only been subpoenaed for a deposition on that topic once, which was enough for me. |
GCC is GPL licensed |
@jnk0le: gcc and binutils are both safe. The thead, ventana, and sifive vendor extensions contributed to binutils are probably equally safe. I'm unsure about the others. |
As someone who has contributed to other projects that involve reverse engineering, I can assure you that the reverse-engineering processes that was done in order to create this specific PR is, to the best of my knowledge (IANAL), completely safe. As you can see from the script included in the zip file posted earlier, I performed the entire process by running controlled inputs through the vendor toolchain and observing the bytes that come out. In no case did I ever load vendor tools themselves into Ghidra or any other disassembler. The bit patterns and pcode in this PR describe only facts and information (and are my own expression of such, not the vendor's), so I do not believe the vendor can make any copyright claims to it. I am less familiar with patent law and did not read any patents while doing this work, but, as this PR doesn't involve implementing a RISC-V core itself, I find it unlikely that there is a legitimate patent claim to... decoding some opcodes for a disassembler. In any case, I believe this discussion is far off-topic and out of scope when it comes to discussing this PR in question. |
Does anyone have suggestions on how to name this extension and the processor/language variant within the Ghidra RISCV directory? The wch toolchain provided by @ArcaneNibble names it The Ghidra design questions here are well over my head. They get worse when Ghidra opens a linux-next RISCV-64 kernel, which determines the supported extensions at load time then patches its own executable code to optimize things like bit manipulation and encrypted file system support. |
This PR adds support for the WCH/QingKe "XW" extension, closing issue #6385
This only includes support for the "XW" extension and not any of the other QingKe-specific functionality (i.e. the ARM Cortex-inspired SysTick and interrupt controller)
As part of this, I had to make a duplicate of the existing .cspec file, as some issues seem to arise with it if the core supports only single-precision floating point but not double-precision floating point. I don't know whether this .cspec is actually correct or not, especially for the QingKe-V2 core which only implements RV32ECXW.
I don't know how to make Ghidra correctly pick the correct variant based on
.riscv.attributes
.The XW opcode disassembly was tested by feeding all possible opcodes (as far as I can tell) through the vendor toolchain, opening the resulting .o into Ghidra, and then visually scanning the results.