[C API] WASI hostcalls crash when lucet-runtime and lucet-wasi are linked dynamically

[acfoltzer]

... 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" fns into lucet-runtime, which lucet-wasi does not depend on, but doing the same trick with this TLS variable is going to be difficult.

[enjhnsn2]

Has there been any progress with this issue, or did you find any sort of workaround?

[shravanrn]

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();
}