Loading global variable returns incorrect (zero) value

[greenhat]

Discovered in get_inputs test.
Loading __stack_pointer in MASM loads incorrect(zero instead of 1048576) value in MASM.

Wasm:

...
  (func $entrypoint (;3;) (type 3) (param i32)
    (local i32 i32 i32)
    global.get $__stack_pointer
    ...
  )
  ...
  (global $__stack_pointer (;0;) (mut i32) i32.const 1048576)

HIR:

...
    (module #abi_transform_tx_kernel_get_inputs_4
        ;; Constants
        (const (id 0) 0x00100000)

        ;; Global Variables
        (global (export #__stack_pointer) (id 0) (type i32) (const 0))

        ;; Functions
        (func (export #entrypoint) (param i32)
            (block 0 (param v0 i32)
                (let (v1 i32) (const.i32 0))
                (let (v2 i32) (global.load i32 (global.symbol #__stack_pointer)))
                ...

MASM:

...
export.entrypoint
    mem_load.0x00000000
    push.16
    u32wrapping_sub
...

[bitwalker]

So, one thing to be aware of: the stack pointer address should actually be zero (LLVM places it at the start of linear memory when compiling to Wasm).

Because there are no data segments, the global table is being placed at the start of the linear memory (address zero), and stack_pointer appears to be the first global in the table.

The actual bug though, I think, is that we're not reserving the first 64k page for the stack. LLVM does this when compiling to memory, but it doesn't look like that is coming through when translating to the IR (i.e. I'd expect a data segment for the stack, but we may have to always assume the first 64k is reserved.

[greenhat]

Oh, you're right! The memory address can and should be zero. I just messed up the global var value with its address.

So the problem I'm experiencing (assert_i32 failing) is that at this zero address 1048576 value is expected to be stored (initial global variable value, see Wasm above), which is not the case. The loaded value is zero, so the next 0 - 16 ops produces the unexpected value (instead of 1048576 - 16 = 1048560).
You mentioned that you are working on rodata init, so you might already know about this issue.

[bitwalker]

This seems to be fixed as of #278, at least I have specifically exercised tests which contain uses of the __stack_pointer global that are working and verified manually that they are at the correct address, and that loads/stores to that global load the expected value, so I'm closing this for now.