wasmtime fails to compile with could not find `fde` in `isa` within: crates/environ/src/data_structures.rs:18:41 on arm

[stefson]

there's a recent regression in the code:

     Running `rustc --crate-name wasmtime_environ --edition=2018 crates/environ/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=3f3bb9806de25bbc -C extra-filename=-3f3bb9806de25bbc --out-dir /tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps --target armv7-unknown-linux-gnueabihf -C linker=armv7a-unknown-linux-gnueabihf-gcc -C incremental=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/incremental -L dependency=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps -L dependency=/tmp/wasmtime/target/debug/deps --extern anyhow=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libanyhow-a7d5a95d013f511f.rmeta --extern base64=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libbase64-1fc3337a027c3d46.rmeta --extern bincode=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libbincode-0cfacf3864ed393b.rmeta --extern cranelift_codegen=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libcranelift_codegen-fe4d1e7b8c528231.rmeta --extern cranelift_entity=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libcranelift_entity-6f3c3d46881e39ec.rmeta --extern cranelift_wasm=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libcranelift_wasm-c3fa487d86de75b7.rmeta --extern directories=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libdirectories-32547e134205d970.rmeta --extern errno=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/liberrno-aa6b44df9b99329e.rmeta --extern file_per_thread_logger=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libfile_per_thread_logger-c9cdc123d34b0b2e.rmeta --extern indexmap=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libindexmap-062ef480b02be0ea.rmeta --extern libc=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/liblibc-45ed8421ceb1d133.rmeta --extern log=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/liblog-4ab7a3e889d23791.rmeta --extern more_asserts=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libmore_asserts-4602433f0d9089cb.rmeta --extern rayon=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/librayon-8631c1a88fa6e275.rmeta --extern serde=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libserde-198981066e594298.rmeta --extern sha2=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libsha2-39588d910b40a085.rmeta --extern thiserror=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libthiserror-8289a6a6c6a57ad6.rmeta --extern toml=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libtoml-6acf23745dbe4062.rmeta --extern wasmparser=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libwasmparser-6bba5d41f47f7b65.rmeta --extern zstd=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/deps/libzstd-4a14a693b151a604.rmeta -L native=/tmp/wasmtime/target/armv7-unknown-linux-gnueabihf/debug/build/zstd-sys-8fe68259522e1833/out`
error[E0432]: unresolved import `cranelift_codegen::isa::fde`
  --> crates/environ/src/data_structures.rs:18:41
   |
18 |         pub use cranelift_codegen::isa::fde::map_reg;
   |                                         ^^^ could not find `fde` in `isa`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `wasmtime-environ`.

caused by: https://github.com/bytecodealliance/wasmtime/commit/d3df27500334625f463ea0f8134ea28395a5e6a0

reverting the commit locally fixes the issue for me.

[bjorn3]

The fde module is gated on x86. Maybe it should just always be compiled?

[abrown]

Yeah, sorry about this one; in #1245 I removed a duplicate instance of map_reg and had to add this new path. Since map_reg is really only implemented for x86, will you still get an error on ARM (but a runtime error instead)?

[bjorn3]

Since map_reg is really only implemented for x86, will you still get an error on ARM (but a runtime error instead)?

Yes it checks for x86 being the target isa at the beginning.

[abrown]

That's what I linked to in my comment above but not what I mean: is map_reg a function that is going to be called in whatever way @stefson is using wasmtime? I.e., I think it has something to do with debug so he may or may not be using it.

[stefson]

I'm actually trying regularly to compile wasmtime, and cranelift, with armv7 to prevent it from breaking further and further. I know that wasmtime most likely hasn't been ported yet to arm, just can't be sure since it never actually built for me ;-) but that approach finds more unrelated bugs such as in yanix

All of my testing and reporting is done with the intention to help you, sadly I don't know much about rust to fix the error myself.

[bjorn3]

I know that wasmtime most likely hasn't been ported yet to arm

The arm backend of Cranelift is little more than a stub. There is currently work being done to completely replace it with a fully functional backend:

https://bytecodealliance.zulipchat.com/#narrow/stream/225524-cranelift-new-backend
https://github.com/cfallin/wasmtime/

[abrown]

Ok, that information helps. I think there are two ways of fixing this:

1. to just get the ARM building, I could remove the feature flag on x86; then users encounter a runtime error if they try to use this FDE functionality but at least it compiles
2. to make map_reg functional on other platforms, we could either move map_reg out of the x86 module or create separate map_reg functions in all of the ISA modules.

I'm leaning towards option 1 (with some added comments linking to this issue) until @cfallin's branch is upstreamed, at which point a lot of this type of stuff needs to be looked at again. What do you all think?

[peterhuene]

Note that some of this is hopefully changing (fixed?) in #1466 too. I haven't yet checked the build for arm though.

The big change in #1466 is that unwind information representation isn't gated on a particular ISA, only the unwind feature. The unwind information would now be an enumeration of all supported ABIs for unwind, which currently is Windows x64 (i.e. a runtime function table) and System V (an .eh_frame).

Currently only the x86-64 ISA supports creating unwind information.

[peterhuene]

@abrown pointed out that #1466 doesn't solve the issue, just shuffles map_reg around so it's still a problem.

I lean towards perhaps a TargetIsa method used to translate a ISA-specific Cranelift register to a Gimli Register with a default implementation that errors unsupported?

[abrown]

That sounds good; should we figure out some way to avoid depending on Gimli in the public API? I mean, we currently depend on a Gimli type in map_reg, but that was a short-term solution.

[peterhuene]

That would make sense not to expose. Perhaps just a map_dwarf_register method and have it return a u16, which is what gimli's Register wraps anyway?