Stream: git-wasmtime

Topic: wasmtime / issue #5563 Cranelift: cannot generate relocat...

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2023 at 04:51):

zeldovich opened issue #5563:

.wat Test Case

(module
  (type (;0;) (func (param f64) (result f64)))
  (func $f (type 0) (param f64) (result f64)
    local.get 0
    f64.floor))

Steps to Reproduce

Expected Results

I would expect wasmtime / cranelift to be able to compile this code on a machine with has_sse41=false. (In particular, this shows up in a QEMU VM.)

Actual Results

I get an error:

thread 'main' panicked at 'not implemented: cannot generate relocation against libcall FloorF64', crates/cranelift/src/obj.rs:155:21

Versions and Environment

Cranelift version or commit: 4.0.0

Operating system: Linux 6.1.3

Architecture: x86_64; the problem shows up in a QEMU VM where has_sse41=false, but can also be observed outside of a QEMU VM by explicitly passing has_sse41=false like above.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2023 at 04:51):

zeldovich labeled issue #5563:

.wat Test Case

(module
  (type (;0;) (func (param f64) (result f64)))
  (func $f (type 0) (param f64) (result f64)
    local.get 0
    f64.floor))

Steps to Reproduce

Expected Results

I would expect wasmtime / cranelift to be able to compile this code on a machine with has_sse41=false. (In particular, this shows up in a QEMU VM.)

Actual Results

I get an error:

thread 'main' panicked at 'not implemented: cannot generate relocation against libcall FloorF64', crates/cranelift/src/obj.rs:155:21

Versions and Environment

Cranelift version or commit: 4.0.0

Operating system: Linux 6.1.3

Architecture: x86_64; the problem shows up in a QEMU VM where has_sse41=false, but can also be observed outside of a QEMU VM by explicitly passing has_sse41=false like above.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2023 at 04:51):

zeldovich labeled issue #5563:

.wat Test Case

(module
  (type (;0;) (func (param f64) (result f64)))
  (func $f (type 0) (param f64) (result f64)
    local.get 0
    f64.floor))

Steps to Reproduce

Expected Results

I would expect wasmtime / cranelift to be able to compile this code on a machine with has_sse41=false. (In particular, this shows up in a QEMU VM.)

Actual Results

I get an error:

thread 'main' panicked at 'not implemented: cannot generate relocation against libcall FloorF64', crates/cranelift/src/obj.rs:155:21

Versions and Environment

Cranelift version or commit: 4.0.0

Operating system: Linux 6.1.3

Architecture: x86_64; the problem shows up in a QEMU VM where has_sse41=false, but can also be observed outside of a QEMU VM by explicitly passing has_sse41=false like above.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2023 at 15:12):

alexcrichton labeled issue #5563:

.wat Test Case

(module
  (type (;0;) (func (param f64) (result f64)))
  (func $f (type 0) (param f64) (result f64)
    local.get 0
    f64.floor))

Steps to Reproduce

Expected Results

I would expect wasmtime / cranelift to be able to compile this code on a machine with has_sse41=false. (In particular, this shows up in a QEMU VM.)

Actual Results

I get an error:

thread 'main' panicked at 'not implemented: cannot generate relocation against libcall FloorF64', crates/cranelift/src/obj.rs:155:21

Versions and Environment

Cranelift version or commit: 4.0.0

Operating system: Linux 6.1.3

Architecture: x86_64; the problem shows up in a QEMU VM where has_sse41=false, but can also be observed outside of a QEMU VM by explicitly passing has_sse41=false like above.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2023 at 15:31):

alexcrichton commented on issue #5563:

Thanks for the report! I believe this is a bug where it was mistakenly assumed that SSE4.2 would always be available, but that's only for when simd is enabled, not for the general baseline. This I think used to work in Wasmtime some time ago but I think I broke it with refactorings a year or so ago.

That being said this seems reasonable to me to support, but supporting this will require a bit of careful planning. The main trickiness here is that this would be the first-of-its-kind to be a relocation that needs to be resolved when an object is loaded. Currently Wasmtime has no relocations to support at that time which improves the load time of objects. Supporting this will be somewhat nontrivial but I still think is reasonable to implement.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 18 2023 at 15:04):

alexcrichton closed issue #5563:

.wat Test Case

(module
  (type (;0;) (func (param f64) (result f64)))
  (func $f (type 0) (param f64) (result f64)
    local.get 0
    f64.floor))

Steps to Reproduce

Expected Results

I would expect wasmtime / cranelift to be able to compile this code on a machine with has_sse41=false. (In particular, this shows up in a QEMU VM.)

Actual Results

I get an error:

thread 'main' panicked at 'not implemented: cannot generate relocation against libcall FloorF64', crates/cranelift/src/obj.rs:155:21

Versions and Environment

Cranelift version or commit: 4.0.0

Operating system: Linux 6.1.3

Architecture: x86_64; the problem shows up in a QEMU VM where has_sse41=false, but can also be observed outside of a QEMU VM by explicitly passing has_sse41=false like above.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 18 2023 at 15:04):

alexcrichton closed issue #5563:

.wat Test Case

(module
  (type (;0;) (func (param f64) (result f64)))
  (func $f (type 0) (param f64) (result f64)
    local.get 0
    f64.floor))

Steps to Reproduce

Expected Results

I would expect wasmtime / cranelift to be able to compile this code on a machine with has_sse41=false. (In particular, this shows up in a QEMU VM.)

Actual Results

I get an error:

thread 'main' panicked at 'not implemented: cannot generate relocation against libcall FloorF64', crates/cranelift/src/obj.rs:155:21

Versions and Environment

Cranelift version or commit: 4.0.0

Operating system: Linux 6.1.3

Architecture: x86_64; the problem shows up in a QEMU VM where has_sse41=false, but can also be observed outside of a QEMU VM by explicitly passing has_sse41=false like above.

Last updated: Nov 22 2024 at 16:03 UTC