[BUG] `target-lexicon` does not compile to riscv32

[0xRampey]

Bug Report

Tried to compile wasmer inside the guest but ended up getting this error.

RISC0_DEV_MODE=1 RUST_LOG="[executor]=info" cargo run --release
   Compiling methods v0.1.0 (/Users/prudhvirampey/Documents/stackrlabs/wasmX/methods)
wasm_runner: Starting build for riscv32im-risc0-zkvm-elfs(build)                                                                                           
wasm_runner:    Compiling target-lexicon v0.12.14
wasm_runner:    Compiling bytecheck v0.6.12
wasm_runner:    Compiling hashbrown v0.14.3
wasm_runner:    Compiling byteorder v1.5.0
wasm_runner:    Compiling cranelift-codegen-shared v0.91.1
wasm_runner:    Compiling parking_lot_core v0.9.9
wasm_runner:    Compiling rkyv v0.7.44
wasm_runner:    Compiling lock_api v0.4.11
wasm_runner:    Compiling cranelift-codegen-meta v0.91.1
wasm_runner: error: failed to run custom build command for `target-lexicon v0.12.14`
wasm_runner: 
wasm_runner: Caused by:
wasm_runner:   process didn't exit successfully: `/Users/prudhvirampey/Documents/stackrlabs/wasmX/target/riscv-guest/release/build/target-lexicon-f7aba57ada830245/build-script-build` (exit status: 101)
wasm_runner:   --- stderr
wasm_runner:   thread 'main' panicked at /Users/prudhvirampey/.cargo/registry/src/index.crates.io-6f17d22bba15001f/target-lexicon-0.12.14/build.rs:52:54:
wasm_runner:   Invalid target name: 'riscv32im-risc0-zkvm-elf'
wasm_runner:   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
wasm_runner: warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command 

Motivation

Wondering if this requires upstream target support from the devs of target-lexicon or if there could be a potential workaround in risc0?

Your Environment

• risc0-zkvm version: "0.21.0"
• Rust version: 1.76.0
• Platform/OS: mac (apple silicon)

Additional context

[linear]

ZKVM-415 [BUG] `target-lexicon` does not compile to riscv32

[SchmErik]

Bug Report

Tried to compile wasmer inside the guest but ended up getting this error.

Awesome! I love that project! ... but I'm not sure if it works inside the guest. So there's an open PR here: bytecodealliance/target-lexicon#96 that will add the code. I've pinged the maintainer so hopefully it will be merged/enabled soon... In the meantime you can patch your crate using the directions here: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section

[0xRampey]

Thanks a lot, this is very helpful.
It would be pretty cool to get wasmer running inside risc0. It could save a lot of cycles running an AoT-compiled WASM module vs an interpreted one from wasmi.

[flaub]

I think what we really want is the ability to have WASM transpile into RISC-V, which would indeed save a lot of cycles, and would be done at build time, which means we wouldn't need to get wasmer running inside the guest. This is something we've been thinking about but isn't on the near term roadmap just yet.

[0xRampey]

Agreed, that would be the most efficient way to go about it.
Does this mean that the WASM needs to be compiled to a custom target like riscv32im-risc0-zkvm-elf? There are already some runtimes like wasmer and WAMR that can compile to riscv64 and riscv32 targets respectively. I'd be happy to help contribute here anyway I can.

[flaub]

Yeah, WAMR looks really interesting!

[nlok5923]

I think what we really want is the ability to have WASM transpile into RISC-V, which would indeed save a lot of cycles, and would be done at build time, which means we wouldn't need to get wasmer running inside the guest. This is something we've been thinking about but isn't on the near term roadmap just yet.

Yep, This would be amazing to see if we could compile down wasm-unknownn to riscV target. But can you elaborate a bit on how it would reduce down the computation cycles ?

[flaub]

Compared to running an interpreter, AoT should always win, assuming that it takes anywhere from 2-10 cycles for the interpreter to run a single WASM instruction.