Refactoring the RISCV architecture to Auto-Sync on LLVM

[moste00]

Your checklist for this pull request

• I've documented or updated the documentation of every API function and struct this PR changes.
• I've added tests that prove my fix is effective or that my feature works (if possible)

Detailed description

This PR is attempting to refactor the RISCV architecture to be updatable from the Auto-Sync tool, such that it automatically follows RISCV-in-LLVM additions and fixes. Following the refactoring guide

depends-on: capstone-engine/llvm-capstone#83

Test plan

...

Closing issues

...

[Rot127]

cc @hainest You are probably aware of this PR, just wanted to ping you as well. Because you mentioned in the Zydis discussion you use Capstone for RISCV as well.

[hainest]

cc @hainest You are probably aware of this PR, just wanted to ping you as well. Because you mentioned in the Zydis discussion you use Capstone for RISCV as well.

I had not seen this. @wxrdnx have you looked at this?

[Rot127]

In response to above. Please stick with the Capstone flag naming convention.
Is RSICV32 is anything else than just 32bit?

[moste00]

You have a point, but I don't know, RISCV[32|64] and RISCVC were legacy flags that were already in the old plugin, so I kept them.

Removing them would probably not affect anything but just be a hassle, it could also be the case that the generated code references them from lots of places and changing the generated code is always a hassle.

[Rot127]

generated code references them

Which one? The test files from the MCUpdater? Those ones can be replaced as described here #2756 (comment)

[moste00]

@Rot127 sorry for the late reply, yes, only the yaml MC tests reference those values, plus a few references in handwritten code in the cstool.c and so on, so it's doable to replace them, will do.

Although this might break APIs, because I see some Python usage from my editor search, until now I have avoided deleting enum members from includes/riscv.h, that's why we still have CS_MODE_RISCV_C and CS_MODE_RISCVC.

[Rot127]

Please check out the helper functions in Mapping.h. They should always be used for these tasks. Because they do bounds checking and such. Accessing the struct members directly (e.g. like details->groups[details->groups_count]) should be the absolute exception, not the rule.

You can also see how the helpers are used in other architectures and just do it the same way. LoongArch is a good example, because it is relatively simple.
AArch64 has many very complex operands. You can check its code if you need examples for these cases.

[Rot127]

The conflicts are coming from the clang-format formatting we did recently btw. So nothing to preserve there.
You can just accept all your changes.

[Rot127]

@moste00 One exceptionally important thing still missing is the documentation in the v6 release guide. It is the first thing we will send people to for questions.

[Rot127]

You know it already, but terrific job you did there!
Thanks a lot!

I have only this last change.
Otherwise this lgtm.