Stream: git-wasmtime

Topic: wasmtime / Issue #1471 wasmtime fails to compile with cou...


view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2020 at 13:02):

stefson opened Issue #1471:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2020 at 13:02):

stefson labeled Issue #1471:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 04 2020 at 14:30):

bjorn3 commented on Issue #1471:

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

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 14:38):

abrown commented on Issue #1471:

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)?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 15:06):

bjorn3 commented on Issue #1471:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 15:31):

abrown commented on Issue #1471:

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?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 15:32):

abrown edited a comment on Issue #1471:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 08:25):

stefson commented on Issue #1471:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 08:51):

bjorn3 commented on Issue #1471:

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

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 08:51):

bjorn3 edited a comment on Issue #1471:

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/

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 15:53):

abrown commented on Issue #1471:

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
  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?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 15:54):

abrown edited a comment on Issue #1471:

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?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:38):

peterhuene commented on Issue #1471:

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

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:46):

peterhuene edited a comment on Issue #1471:

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

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 20:43):

peterhuene commented on Issue #1471:

@abrown pointed out that #1466 doesn't solve the issue, just shuffles reg_map 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?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 20:43):

peterhuene edited a comment on Issue #1471:

@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?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 20:48):

abrown commented on Issue #1471:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 20:57):

peterhuene commented on Issue #1471:

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?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 21:01):

peterhuene edited a comment on Issue #1471:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 16:45):

abrown closed Issue #1471:

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.


Last updated: Nov 22 2024 at 17:03 UTC