Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading global variable returns incorrect (zero) value #248

Closed
greenhat opened this issue Jul 18, 2024 · 3 comments
Closed

Loading global variable returns incorrect (zero) value #248

greenhat opened this issue Jul 18, 2024 · 3 comments
Assignees
Milestone

Comments

@greenhat
Copy link
Contributor

greenhat commented Jul 18, 2024

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
...
@greenhat greenhat added this to the Alpha milestone Jul 18, 2024
@bitwalker
Copy link
Contributor

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
Copy link
Contributor Author

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.

@greenhat greenhat changed the title Loading global variable uses incorrect address (zero) Loading global variable returns incorrect (zero) value Jul 19, 2024
@bitwalker bitwalker self-assigned this Jul 22, 2024
@bitwalker
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

2 participants