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.
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.
bjorn3 commented on Issue #1471:
The
fde
module is gated on x86. Maybe it should just always be compiled?
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. Sincemap_reg
is really only implemented for x86, will you still get an error on ARM (but a runtime error instead)?
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.
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?
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.
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.
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
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/
abrown commented on Issue #1471:
Ok, that information helps. I think there are two ways of fixing this:
- 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
- to make
map_reg
functional on other platforms, we could either movemap_reg
out of the x86 module or create separatemap_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?
abrown edited a comment on Issue #1471:
Ok, that information helps. I think there are two ways of fixing this:
- 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
- to make
map_reg
functional on other platforms, we could either movemap_reg
out of the x86 module or create separatemap_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 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.
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.
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 GimliRegister
with a default implementation that errors unsupported?
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 GimliRegister
with a default implementation that errors unsupported?
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.
peterhuene commented on Issue #1471:
That would make sense not to expose. Perhaps just a
map_dwarf_register
method and have it return au16
, which is what gimli'sRegister
wraps anyway?
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.
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