RISC-V fixes

[wakabat]

This commit contains several RISC-V fixes we've accumulated:

• Handle more RISC-V allocations
• Metadata must be aligned by 8
• Pass pointer width instead of hardcoding it to 8
• Implement trampoline for rv32

It fixes problems using wasmer in rv32, but for now the code does not aim to enable rv32. I feel like it is a bigger decision.

[wakabat]

@marxin So this is what I have to replace #5521. I have to mention that many changes included in this PR has to do with rv32, while wasmer does not officially support rv32.

We can of course talk about it, and discuss how much in this PR shall be merged into wasmer.

[marxin]

@marxin So this is what I have to replace #5521. I have to mention that many changes included in this PR has to do with rv32, while wasmer does not officially support rv32.

Thank you for the PR, generally speaking, LGTM.

We can of course talk about it, and discuss how much in this PR shall be merged into wasmer.

I would like to see a full support of the rv32 target with LLVM - do you know what's missing on top of this pull request? Btw. can one test rv32 on a Linux system running rv64gc system?

[wakabat]

For our case, the only remaining work to support rv32, is merely enabling it in this file.

And I don't believe you can test rv32 code in rv64gc platform, you need a real rv32 chip or VM setup.

[marxin]

For our case, the only remaining work to support rv32, is merely enabling it in this file.

All right, then include it in this PR so that it's a self-contained set of changes. And note I added a couple of relocations in the #6020 PR. This PR needs to be rebased.

And I don't believe you can test rv32 code in rv64gc platform, you need a real rv32 chip or VM setup.

Frankly speaking, we can definitely add rv32 support, but as of now, we don't have any development board we can test it on.

[wakabat]

This is rebased, I've also tweaked LLVM compiler's config to introduce rv32 targets.

as of now, we don't have any development board we can test it on.

I totally agree that a real board can never be replaced in many tests, e.g., performance analysis. But if we are limiting the goal to correctness testing, I personally believe qemu-user package can be quite handy.

In addition, I would recommend having an environment where the host is 64-bit and the target is 32-bit, it helps uncover certain types of bugs, where pointer size of the host platform is used for target code.

[marxin]

This is rebased, I've also tweaked LLVM compiler's config to introduce rv32 targets.

Great, please rename the PR as it's now purely about the rv32 target addition. And one more rebase will be needed.

But if we are limiting the goal to correctness testing, I personally believe qemu-user package can be quite handy.

Speaking about the qemu cross compilation - we inherently need to have a cross LLVM binaries (something like https://github.com/mean00/LLVM-embedded-toolchain-for-rv32). Do you have any experience with that? I am all ears!