x64: Misaligned load fault with sunk float operation when AVX disabled

[alexcrichton]

Currently on the main branch this fails:

$ cargo run -q wast --target x86_64-unknown-linux-gnu -Oopt-level=0 ./tests/misc_testsuite/issue4890.wast
Error: failed to run script file './tests/misc_testsuite/issue4890.wast'

Caused by:
    0: failed directive on ./tests/misc_testsuite/issue4890.wast:12:1
    1: error while executing at wasm backtrace:
           0:   0x2f - <unknown>!<wasm function 0>
    2: wasm trap: out of bounds memory access

This test shouldn't fail, however, and it should pass. Bisection points to #10316 (ddaaed6).

Using #10405 I get

$ cargo run -q objdump foo.cwasm --traps --addresses
00000000 wasm[0]::function[0]:
         0: pushq   %rbp
         1: movq    %rsp, %rbp
         4: movl    %edx, %r11d
         7: addq    0x50(%rdi), %r11
         b: movl    $0x80000000, %r8d
        11: movd    %r8d, %xmm1
        16: movdqa  %xmm1, %xmm0
        1a: andnps  0xf(%rip), %xmm0
        21: andps   1(%r11), %xmm1
            ╰─╼ trap: MemoryOutOfBounds
        26: orps    %xmm1, %xmm0
        29: movq    %rbp, %rsp
        2c: popq    %rbp
        2d: retq
        2e: addb    %al, (%rax)
        30: addb    %al, (%rax)
        32: addb    %al, (%rax)
        34: addb    %al, (%rax)
        36: addb    %al, (%rax)
        38: addb    %al, (%rax)
        3a: addb    %al, (%rax)
        3c: addb    %al, (%rax)
        3e: addb    %al, (%rax)

and the bug here is indeed that MemoryOutOfBounds trap happening. That's due to misalignment though instead of something being out-of-bounds so we're erroneously catching the segfault.

cc @abrown @rahulchaphalkar

[alexcrichton]

I'll note that this is NOT on the release-31.0.0 branch, so this does not affect the pending release in a few days, so we have ~6 weeks to fix this.

[alexcrichton]

I tried double-checking just now, but ideally we wouldn't catch segfaults related to misalignment at all. I'm not sure if misalignment faults look different from normal segfaults though at the hardware level, but at the libc level they seem to look the same. Debugging some fields in siginfo_t I get:

si_code=128
si_errno=0
si_signo=11
si_trapno=0

where it looks like nothing is alignment-vs-unmapped here. The si_code means "is from the kernel" and si_signo is SIGSEGV.

[alexcrichton]

Hm ok correction: the release-31.0.0 branch does contain #10273 (e33c426) which may be affected by this. This test itself does not literally fail on the release branch. Manually auditing rules I don't think that load-sinking behavior is reachable from x64_orpd, all arguments are always Xmm except for the bor instruction in Cranelift which isn't supported on floats in wasm anyway.