WAMR JIT mode shows "unreachable" instead of "out of bounds".

[teyahb8]

Subject of the issue

I executed the following test case with different runtimes. Other runtimes and also WAMR's AOT mode gives an "out of bounds" exception whereas WAMR's JIT mode gives an "unreachable" exception.

Test case

(module
  (type (;0;) (func (param i32 i32 i32 i32) (result i32)))
  (type (;1;) (func (param i32)))
  (type (;2;) (func))
  (type (;3;) (func (result i32)))
  (type (;4;) (func (result v128)))
  (table (;0;) 10 20 funcref)
  (memory (;0;) 1 5)
  (global (;0;) i32 i32.const 541)
  (global (;1;) (mut i32) i32.const 191)
  (global (;2;) f32 f32.const 0x1.0e8p+9 (;=541;))
  (global (;3;) (mut f32) f32.const 0x1.8p+7 (;=192;))
  (global (;4;) i64 i64.const 54)
  (global (;5;) (mut i64) i64.const 19)
  (global (;6;) f64 f64.const 0x1.bp+5 (;=54;))
  (global (;7;) (mut f64) f64.const 0x1.3p+4 (;=19;))
  (global (;8;) (mut i32) i32.const 0)
  (global (;9;) (mut f32) f32.const 0x0p+0 (;=0;))
  (global (;10;) (mut i64) i64.const 0)
  (global (;11;) (mut f64) f64.const 0x0p+0 (;=0;))
  (export "main" (func 0))
  (export "to_test" (func 0))
  (elem (;0;) (i32.const 0) func 1 2 3 0 1)
  (elem (;1;) (i32.const 5) func 3 3 2 1)
  (elem (;2;) (i32.const 9) func 0)
  (func (;0;) (type 4) (result v128)
    (local i32 f32 i64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64 f64)
    i32.const 305419896
    local.set 0
    f32.const 0x1.8cp+6 (;=99;)
    local.set 1
    i64.const -72057589709208571
    local.set 2
    f64.const 0x1.5f0b08c960a79p+109 (;=890000000000000000000000000000000;)
    local.set 3
    i32.const 2147483647
    v128.load align=1
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    unreachable
    v128.load16_lane offset=49423 align=1 1
    local.get 0
    global.set 8
    local.get 1
    global.set 9
    local.get 2
    global.set 10
    local.get 3
    global.set 11
  )
  (func (;1;) (type 3) (result i32)
    i32.const 1
    i32.const 3
    i32.add
  )
  (func (;2;) (type 3) (result i32)
    i32.const 2
    i32.const 3
    i32.add
  )
  (func (;3;) (type 3) (result i32)
    i32.const 3
    i32.const 3
    i32.add
  )
  (data (;0;) (i32.const 8) "\01\02\03\04\05\06\07\08")
  (data (;1;) (i32.const 16) "\01\02\03\04\05\06\07\08\ff")
  (data (;2;) (i32.const 32) "\01\02\03\04\05\06\07\08\ff")
)

Your environment

• Host OS: Ubuntu 22.04
• WAMR version (2.3.1), platform (Linux), cpu architecture (x86_64), running mode (JIT), etc.

Steps to reproduce

Run iwasm --heap-size=0 --llvm-jit -f to_test v128.load16_lane_7491_1_17520275478991027.wasm

Expected behavior

Should output "Exception: out of bounds".

Actual behavior

Actually outputs "Exception: unreachable".

Extra Info

Can you please confirm if this looks like a bug? Thanks in advance.

[Septa2112]

I created a smaller .wat test case and ran an experiment:

When I remove all unreachable instructions, the LLVM-JIT will correctly throws Exception: out of bounds memory access.
However, when I include the unreachable instructions, the exception changes to Exception: unreachable.

This difference is likely due to LLVM-JIT's optimization behavior. Since all execution paths eventually lead to an unreachable instruction, LLVM-JIT may treat v128.load as dead code and optimize them away.

As a result, the v128.load instruction is never actually executed. Because this does not break the sandboxing guarantees, the out-of-bounds access is never triggered, and the program instead traps on the unreachable instruction.

---

Dump Results

In my .wat file, I changed the type from v128 to i64, but this had no effect on the debugging result. Here are parts of dump results:

Version without unreachable

...
define i64 @"aot_func#0"(ptr %exec_env) {
func_begin:
  %aot_inst_addr = getelementptr inbounds ptr, ptr %exec_env, i64 2
  %aot_inst = load ptr, ptr %aot_inst_addr, align 8
  %0 = getelementptr inbounds i8, ptr %aot_inst, i64 376
  %mem_base_addr2 = load i64, ptr %0, align 8
  %1 = inttoptr i64 %mem_base_addr2 to ptr
  %maddr = getelementptr inbounds i8, ptr %1, i64 2147483647
  %data = load i64, ptr %maddr, align 1
  ret i64 %data
}
...

Version with unreachable

...
define i64 @"aot_func#0"(ptr %exec_env) {
func_begin:
  %aot_inst_addr = getelementptr inbounds ptr, ptr %exec_env, i64 2
  %aot_inst = load ptr, ptr %aot_inst_addr, align 8
  call void inttoptr (i64 93982511588777 to ptr)(ptr %aot_inst, i32 0)
  ret i64 0
}
...

This supports the hypothesis that LLVM optimizations are responsible for the change in observed runtime behavior.

[teyahb8]

Thanks for the nice explanation.