petrpavlu / valgrind-riscv64 Goto Github PK

Do you think it's feasible to make a tool for valgrind to convert RV32 code to RV64 on the fly?

e.g. see slli or c.slli, pretend you saw slliw, etc.

It seems that if you want to simply run the code then QEMU is faster. On my primes benchmark [1] running an RV64 binary on VisionFive 2 using qemu-riscv64-static gives a slowdown of 8x while valgrind --tool=none gives a 17x slowdown. qemu-riscv32-static (on rv64) is essentially the same speed as the rv64 version.

But valgrind has additional bug finding benefits.

Of course both of these are converting the RISC-V code to a generic IL and then JITing it back to RISC-V. It would be much more efficient to have something that knew it was doing RISC-V --> RISC-V and left most of the instructions untouched, only rewriting the needed instructions (which can result in code expansion because of e.g. c.slli not having a W equivalent in the C extension.

Thoughts?

I know the original VMWare did x86 -> x86 JIT, changing only the instructions that were virtualisation holes. I don't know if there is anything like that for RISC-V (which of course doesn't have virtualisation holes)

[1] http://hoult.org/primes.txt

This is great!

Unfortunately I can't use it on my Lichee Pi 4A (TH1520 SoC, THead C910 cores) because before it gets to my code:

disInstr(riscv64): unhandled instruction 0x01A0000B

That's th.sync.i. Which is probably only the first of many such instructions, including lots from XTheadBa, XTheadBb etc, even though my own code is compiled for generic RV64GC.

Fortunately it works fine on my VisionFive 2, as long as I don't compile my code with Zba or Zbb. If I do then it fails (on my current program of interest) with:

disInstr(riscv64): unhandled instruction 0x20BECE33

... which is sh2add.

Any plans to add support for these?

I could maybe figure out how to add just the ones my code is actually using. I haven't looked at the internals yet.

in order to support riscv,Made what changes?

Hi,
Amazing work!
Do we have a plan to let Valgrind upstream merge this feature?
If there are need help with real riscv64 hardware resources, please let me know.
Thanks again for your great work~

Building on FreeBSD amd64 with clang13 I get

priv/guest_riscv64_helpers.c:256:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:261:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:266:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:271:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:276:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:281:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:286:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:291:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:296:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]
priv/guest_riscv64_helpers.c:301:9: warning: unused variable 'rm_RISCV' [-Wunused-variable]

I would like to help you solve issues or introduce enhancements. Feel free to work together.

priv/guest_riscv64_toIR.c:1621:14: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
 1621 |          if (fm = 0b1000)
      |              ^~

Should probably be "=="

First, I get these

memcheck/tests/riscv64-linux/context_float (stdout)
memcheck/tests/riscv64-linux/context_float (stderr)
memcheck/tests/riscv64-linux/context_integer (stdout)
memcheck/tests/riscv64-linux/context_integer (stderr)
memcheck/tests/riscv64-linux/scalar      (stderr)
...
Unknown directory 'riscv64'. Please update check_headers_and_includes

I also get 2 new failures

memcheck/tests/leak-segv-jmp (stderr)

That looks like a line number change due to added RISCV64 code in the .c file and the expected needs updating.

none/tests/libvexmultiarch_test (stderr)

paulf> cat none/tests/libvexmultiarch_test*diff
--- libvexmultiarch_test.stderr.exp     2023-01-29 09:36:06.883182000 +0100
+++ libvexmultiarch_test.stderr.out     2023-01-29 10:16:07.617645000 +0100
@@ -0,0 +1 @@
+valgrind: ./libvexmultiarch_test: No such file or directory

I see that this is marked as 'disable for now'. As a quick fix you could put in the .vgtest

prereq: ! ../../test/arch_test riscv64

@paulfloyd @petrpavlu
We consider to add RVV/Vector feature in valgrind and met some issues from investigation.

RVV like ARM's SVE programming model, it's scalable/VLA, that means the vector length is agnostic.
ARM's SVE is not supported in valgrind :(

There is not any VLA vector IR to represent these vector model, it's the big issue.
Also some other common module like "register allocator" in VEX can not represent vector type which use
more than one register.
In another hand, some tool plugin like Memcheck will use data type like "Ity_V128/Ity_V256" to generate IRs, it's a big challenge

Any ideas for supporting of scalable vector model ?