Rust Bindings for the V8 C++ WebAssembly API

[jul-sh]

As of v7.8 V8 implements the Wasm C/C++ API proposal. This API is implemented as a separate V8 build target producing a library called libwee8. This library supports only WebAssembly, no JavaScript.

Are there plans / is there desire to create Rust bindings for libwee8?

Ref: https://github.com/project-oak/oak/issues/74

[ry]

We don't have any explicit plans yet, but we want to do this.

Half of the problem rusty_v8 solves is providing build system integration between gn and cargo and providing a CI that produces release binaries (since V8 takes so long to build from scratch) - we can (and should) reuse that infrastructure to provide a Rust version of wee8. I guess we ought to produce a separate crate (rusty_v8_wee8 ?) that allows people to link to it.

[bnoordhuis]

Practical issue: V8's libwee8.a target depends on libv8.a. I suspect you won't be able to use rusty_v8 and rusty_v8_wee8 together (because of duplicate C++ symbols during the final link) unless the latter crate depends on the former to provide libv8.a.

Not sure how easy it is to set that up. It sounds pretty hard, actually. :-)

It might be easier to compile everything into rusty_v8 and have it re-export the WASM C-API symbols:

diff --git a/BUILD.gn b/BUILD.gn
index a0624d7..1ee8f50 100644
--- a/BUILD.gn
+++ b/BUILD.gn
@@ -2,7 +2,13 @@
 
 static_library("rusty_v8") {
   complete_static_lib = true
-  sources = [ "src/binding.cc" ]
+  sources = [
+    "src/binding.cc",
+    "v8/src/wasm/c-api.cc",
+    "v8/src/wasm/c-api.h",
+    "v8/third_party/wasm-api/wasm.h",
+    "v8/third_party/wasm-api/wasm.hh",
+  ]
   deps = [
     "//build/config:shared_library_deps",
     "//v8:v8",

extern "C" {
  fn wasm_config_new() -> *mut wasm_config_t;
  fn wasm_engine_new() -> *mut wasm_engine_t;
  // etc.
}

[bnoordhuis]

I posted a small proof of concept in #495 to validate the approach.

[abrown]

I have been looking around for a good way to use V8's Wasm features from Rust and this might fit the bill: is there a plan to release a finished version of #495 in rusty_v8? And, if so, how much more is left to do there?

[abrown]

(I guess the alternative would be to expose WasmModuleObject and related classes?)

[bnoordhuis]

how much more is left to do there?

A lot :-) - currently there's only enough to start up and tear down the WASM runtime.

v8::WasmModuleObject is orthogonal to what this issue asks for. It's part of the mechanism underpinning WebAssembly.compileStreaming(), i.e., JS+WASM integration, not the standalone WASM runtime.

[tiziano88]

Was there any more progress on this? We (https://github.com/project-oak/oak) would be very interested in using rusty_v8 if this API were available :)

[bnoordhuis]

@tiziano88 Nothing so far. I don't have concrete plans for picking it back up anytime soon but you're welcome to work on it if you want.