[RISCV][Lifting] Implement RzIL lifting for the rest of the M extension

[moste00]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository.
• I made sure to follow the project's coding style.
• I've documented every RZ_API function and struct this PR changes.
• I've added tests that prove my changes are effective (required for changes to RZ_API).
• I've updated the Rizin book with the relevant information (if needed).
• I've used AI tools to generate fully or partially these code changes and I'm sure the changes are not copyrighted by somebody else.

Detailed description

Continues #6287 by adding more multiplication instructions.

Test plan

...

Closing issues

PR Stack Structure

This PR is the second of a 4-PR stack that lifts the I-M-A-FD RISC-V archiecture plus some privileged instructions.

The following is a table for ease of navigation from any PR to any other, please filter by the commit(s) mentioned in the table when reviewing the diff in the "Files Changed" tab to avoid the noise of the base branches.

Extension	PR	Commits To Select in "Files Changed"	State (Open, Merged, Draft, Closed)
I	#6287	No filtering necessary	O
M	#6364 < (THIS PR)	"implement the rest of the multiplication extension"	D
A	#6373	"implement the atomic extension trivially by ignoring concurrency guards"	D
F/D	#6374	"add floating and double instructions, and add privlieged ISA instructions like reading CSRs to implement fflags reading and writing"	D

Because it's painful to maintain this stack manually with no Github or other tooling support, I won't grow it any further until one of those 4 PRs gets merged.

[notxvilka]

Since there is no tracetesting yet, please start from creating "emulateme" test and implement instructions first that in that particular test binary(ies). Then we can make sure those are more or less correct.

[moste00]

Since there is no tracetesting yet, please start from creating "emulateme" test and implement instructions first that in that particular test binary(ies). Then we can make sure those are more or less correct.

Do you mean there are no tracetesting at all or that there is no tracetesting for the M-extension ? Because there is tracetesting (BinaryAnalysisPlatform/qemu#44, rizinorg/rz-tracetest#29), I ran a very minimal local binary for both 32-bit and 64-bit already, and I made sure that all non-floating-point instructions in it run correctly, this is how a lot of instructions in #6287 are verified indeed.

I didn't run any binary yet for instructions added uniquely in this PR, but I will soon.

(If you meant that I should commit all the binaries that I trace to the binaries repo, I will, but I can't make them target a specific set of extensions without a lot of headache, so I can't make a binary specifically for the M extension, it will contain a lot from other MAFD extensions. I'm seperating the changes by extension for ease of review, but when I run binaries I will always run against IMAFD)

[moste00]

@notxvilka Did you actually mean I shouldn't structure the lifting as extension-by-extension PRs at all, instead proceeding binary-by-binary on real-world binaries ? Good idea but I naturally think in terms of extensions, I can switch gears if that's what you meant.

[notxvilka]

@notxvilka Did you actually mean I shouldn't structure the lifting as extension-by-extension PRs at all, instead proceeding binary-by-binary on real-world binaries ? Good idea but I naturally think in terms of extensions, I can switch gears if that's what you meant.

No, if you already started with the tracetesting, it's fine to keep going as is. It's just priority should be towards more popular instructions compared to less popular, so that it covers all use cases in real binaries.