lucet
lucet copied to clipboard
[C API] WASI hostcalls crash when lucet-runtime and lucet-wasi are linked dynamically
... and possibly statically, but I haven't checked yet.
The problem is that the thread-local variable CURRENT_INSTANCE
, defined in lucet-runtime-internals
, ends up appearing in both liblucet-runtime.so
and liblucet-wasi.so
, but at distinct addresses. So, the lucet-runtime
side sets the variable appropriately when entering Wasm, but then the hostcalls implemented in lucet-wasi
try and fail to get the current instance from lucet-wasi
's copy of the variable. Panic.
Hopefully there's something clever we can do with linking to get around this, because both libraries have to depend on lucet-runtime-internals
, and CURRENT_INSTANCE
has to be defined in that crate so that the signal handler can reference it. We solved similar problems in the past with exported C function symbols by moving all of the pub extern "C" fn
s into lucet-runtime
, which lucet-wasi
does not depend on, but doing the same trick with this TLS variable is going to be difficult.
Has there been any progress with this issue, or did you find any sort of workaround?
Documenting for others. Workaround @enjhnsn2 and I have been using is to create a new rust library project with dependencies to the lucet libraries and outputting a single shared library with all symbols
Cargo.toml contains
authors = ["FILL_IN"]
edition = "2018"
license = "MIT"
[dependencies]
lucet-wasi = { path = "../lucet-wasi" }
lucet-runtime = { path = "../lucet-runtime" }
lucet-runtime-internals = { path = "../lucet-runtime/lucet-runtime-internals" }
lucet-module = { path = "../lucet-module" }
[lib]
name = "lucet_fullrt"
crate-type = ["rlib", "staticlib", "dylib"]
lib.rs contains a function ensuring linking
pub fn ensure_linked() {
lucet_runtime::lucet_internal_ensure_linked();
lucet_wasi::export_wasi_funcs();
}