oddness with stack in llvm output + s2wasm

[vvuk]

With bitcode that looks like this in .ll (yes, unoptimized):

define dllexport i32 @TestMethod() {
entry:
  %var.0. = alloca i32
  br label %BL.entry
BL.entry:                                         ; preds = %entry
  br label %BL.0000
BL.0000:                                          ; preds = %BL.entry
  store i32 5, i32* %var.0., align 1
  br label %BL.0005
BL.0005:                                          ; preds = %BL.0000
  %0 = load i32, i32* %var.0., align 1
  ret i32 %0
}

This generates the following .s using llc --asm-verbose -o bitcode.s bitcode.bc:

	.globl	TestMethod
	.type	TestMethod,@function
TestMethod:
	.result 	i32
	i32.const	$push2=, 0
	i32.load	$push1=, __stack_pointer($pop2)
	i32.const	$push3=, 16
	i32.sub 	$push4=, $pop1, $pop3
	i32.const	$push0=, 5
	i32.store	12($pop4), $pop0
	i32.const	$push5=, 5
	.endfunc

Are those $push2= and $pop2s magic push/pop operands somehow?

Which when it goes through s2wasm:

 (func $TestMethod (; 2 ;) (result i32)
  (i32.store offset=12
   (i32.sub (i32.load offset=4 (i32.const 0)) (i32.const 16))
   (i32.const 5)
  )
  (i32.const 5)
 )

This ends up doing an invalid memory access:

$ wasm-interp foo.wasm --run-all-exports --trace
>>> running export "TestMethod":
#0.    0: V:0  | i32.const $0
#0.    5: V:1  | i32.load $0:0+$4
#0.   14: V:1  | i32.const $16
#0.   19: V:2  | i32.sub 0, 16
#0.   20: V:1  | i32.const $5
#0.   25: V:2  | i32.store $0:4294967280+$12, 5
TestMethod() => error: out of bounds memory access

It looks like this is expecting to manipulate the stack (the __stack_pointer($pop2) thing), but that's turning into... i32.const 0? Yes, I am very confused. :)

[binji]

I'm guessing @kripken will be able to respond better here, but I think the basic problem is that s2wasm is performing some of the responsibilities of linking by assigning the stack pointer a memory location (4). It is assuming that before any code is run the stack will be set up properly, allocating memory and setting the value at address 4 to the top of the stack.

wasm-interp doesn't do any of this, and only runs exactly the code in the .wasm module, so when it reads the stack pointer at address 4 it gets 0. It then tries to allocate more space on the stack (subtracting 16) but ends up underflowing the stack pointer.

In any case, we're trying to move away from s2wasm use. The upstream LLVM backend can now produce .wasm files directly, which follow the behavior as outlined in tool-conventions. Work is also ongoing with using lld as the WebAssembly linker.

Even with those tools, though, I believe there is an implicit assumption that the stack has been set up before any code is run. @sbc100 is that correct?

[sunfishcode]

@binji Yes, that's right.

Also, note that in the tool-conventions ABI, __stack_pointer is a wasm global variable accessed with get_global/set_global rather than being a memory location accessed with load/store.

[jakirkham]

Guess this should be closed as won't fix given s2wasm was dropped. ( #1607 )