Closed tnayuki closed 6 months ago
This looks great! I don't think it would take too much effort to get the universal engine working too, I think you just need to implement support for RISC-V relocations.
Apart from the issues with the LLVM API, I think this looks great!
Thanks! I'll try to implement relocations next.
For starters I just implemented R_RISCV_CALL_PLT relocation, and fizzbuzz runs with universal engine.
But more complex program like coremark.wasm, doesn't works. It seems there are references in wasmer_function section to symbols in section like the following code(constants table?). I wonder if current code support symbols in section other than wasmer_function section.
Disassembly of section .sdata:
0000000000000000 <.LCPI0_0>:
0: 0000 unimp
2: 0000 unimp
4: cd65 beqz a0,fc <.LCPI0_5+0xd4>
6: 41cd li gp,19
0000000000000008 <.LCPI0_1>:
8: 0000 unimp
a: 0000 unimp
c: 0000 unimp
e: 3ff0 fld fa2,248(a5)
0000000000000010 <.LCPI0_2>:
10: 0000 unimp
12: 0000 unimp
14: 0000 unimp
16: 41f0 lw a2,68(a1)
0000000000000018 <.LCPI0_3>:
18: ffff 0xffff
1a: ffff 0xffff
1c: ffff 0xffff
1e: jal gp,ffffffffffff501c <.LBB0_107+0xffffffffffff3e44>
0000000000000020 <.LCPI0_4>:
20: ffff 0xffff
22: ffff 0xffff
24: ffff 0xffff
26: jal t6,b026 <.LBB0_107+0x9e4e>
0000000000000028 <.LCPI0_5>:
28: 0000 unimp
2a: 0000 unimp
2c: 0000 unimp
2e: 4024 lw s1,64(s0)
This seems to be constants generated by LLVM, which are placed in the .sdata
section. You'll need to implement the necessary relocations to support these.
By the way, make sure that linker relaxation is disabled since we are unlikely to support this in Wasmer.
I see, so I guess that means LLVM doesn't generate code like this on x86_64 and aarch64.
I found it's better to match architecture in addition to relocation kind and size here. Because relocation kinds for different architectures may have same values.
For example R_X86_64_PC64 and R_RISCV_PCREL_LO12_I, both are 24
!
That sounds like a good way to match relocations. Let us know once the PR is ready to be reviewed :)
Thanks, I created the pull request https://github.com/wasmerio/wasmer/pull/2783 that has just relocation matching changes described above.
I'm making progress slowly...
Many tests now pass on my HiFIve Unmatched! Left one I need is a portable way to change LLVM ABI...
I created a PR. https://github.com/wasmerio/wasmer/pull/2800
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
not stale
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Feel free to reopen the issue if it has been closed by mistake.
Feel free to reopen the issue if it has been closed by mistake.
I managed to get wasmer starting to work on my HiFive Unmatched RISC-V board. It can now runs FizzBuzz with LLVM compiler and Dylib engine.
But I think it's not yet suitable to make a pull request due to some reasons. I think we should add more RISC-V support to inkwell, llvm-sys and maybe also LLVM C API.
Here is my change: https://github.com/tnayuki/wasmer/commits/risc-v
If anyone else working with the RISC-V support, I would like to hear a better approach.