alexcrichton opened issue #4629:
Similar to https://github.com/bytecodealliance/wasmtime/issues/4626 this popped out of a generated adapter module from the
component_api
fuzzer. Again the type hierarchy is probably a bit too deep here and should validate against it, but still we probably also shouldn't panic on the input:$ export CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS=true $ cargo run --release --features all-arch compile adapter.wasm --wasm-features all --target aarch64 Finished release [optimized] target(s) in 0.21s Running `target/release/wasmtime compile adapter.wasm --wasm-features all` thread '<unnamed>' panicked at 'assertion failed: pc_rel <= self.max_pos_range() as i64', cranelift/codegen/src/isa/aarch64/inst/mod.rs:2760:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
alexcrichton labeled issue #4629:
Similar to https://github.com/bytecodealliance/wasmtime/issues/4626 this popped out of a generated adapter module from the
component_api
fuzzer. Again the type hierarchy is probably a bit too deep here and should validate against it, but still we probably also shouldn't panic on the input:$ export CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS=true $ cargo run --release --features all-arch compile adapter.wasm --wasm-features all --target aarch64 Finished release [optimized] target(s) in 0.21s Running `target/release/wasmtime compile adapter.wasm --wasm-features all` thread '<unnamed>' panicked at 'assertion failed: pc_rel <= self.max_pos_range() as i64', cranelift/codegen/src/isa/aarch64/inst/mod.rs:2760:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
alexcrichton commented on issue #4629:
Oops forgot to attach the actual module: adapter.wasm.gz
alexcrichton commented on issue #4629:
I think this is probably related to https://github.com/bytecodealliance/wasmtime/issues/3277, but the intra-function case rather than the inter-function case.
bjorn3 commented on issue #4629:
I would have expected https://github.com/bytecodealliance/wasmtime/pull/4627 to fix this given that the exact same code is used for intra- and inter-function relocations AFAIK.
cfallin commented on issue #4629:
This appears to be a veneer island that is emitted a few thousand bytes too late: there is a Branch19 at the start of a very large (> 1MiB) function body, and the range of the Branch19 relocation is +/- 1MiB. emit_island is invoked around offset 1050000 (2^20 is 1048576). Looking into it more...
cfallin closed issue #4629:
Similar to https://github.com/bytecodealliance/wasmtime/issues/4626 this popped out of a generated adapter module from the
component_api
fuzzer. Again the type hierarchy is probably a bit too deep here and should validate against it, but still we probably also shouldn't panic on the input:$ export CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS=true $ cargo run --release --features all-arch compile adapter.wasm --wasm-features all --target aarch64 Finished release [optimized] target(s) in 0.21s Running `target/release/wasmtime compile adapter.wasm --wasm-features all` thread '<unnamed>' panicked at 'assertion failed: pc_rel <= self.max_pos_range() as i64', cranelift/codegen/src/isa/aarch64/inst/mod.rs:2760:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Last updated: Dec 23 2024 at 12:05 UTC