__stack_pointer, __memory_base, __table_base missing 4GB handling?

[juj]

emscripten/src/lib/libcore.js

Lines 2187 to 2193 in 7dd9069

	// Globals that are normally exported from the wasm module but in relocatable
	// mode are created here and imported by the module.
	__stack_pointer: "new WebAssembly.Global({'value': '{{{ POINTER_WASM_TYPE }}}', 'mutable': true}, {{{ to64(STACK_HIGH) }}})",
	// tell the memory segments where to place themselves
	__memory_base: "new WebAssembly.Global({'value': '{{{ POINTER_WASM_TYPE }}}', 'mutable': false}, {{{ to64(GLOBAL_BASE) }}})",
	// the wasm backend reserves slot 0 for the NULL function pointer
	__table_base: "new WebAssembly.Global({'value': '{{{ POINTER_WASM_TYPE }}}', 'mutable': false}, {{{ to64(TABLE_BASE) }}})",

These utilize {{{ to64('foo') }}} to handle Wasm64 case. And 2GB memory case is handled by default.

Though shouldn't there be a >>> 0 for 4GB memory mode? Iirc these values come out as int32 also?

[sbc100]

These library elements are basically/largely unused since #25522 landed. Nowadays we don't build the main module with -sRELOCTABLE and I'm hoping to completely remove the option soon.

I don't think it matters here since the values are used in the WebAssembly.Global constructor and this holds an I32 value, which is signed, and cannot hold value larger than 2^^32. The contents of the global are interpreted as unsigned in wasm, but we cannot create

See how it behaves in node:

> v = new WebAssembly.Global({'value': 'i32', 'mutable': true}, (2**31)).value
-2147483648
> v = new WebAssembly.Global({'value': 'i32', 'mutable': true}, -2147483648).value
-2147483648
> v = new WebAssembly.Global({'value': 'i32', 'mutable': true}, -2147483648 >>> 0).value
-2147483648

Note that in all cases we get the same Wasm global value.

[juj]

Oh right, even if those were casted to unsigned, they would result in a signed value being read back. That makes sense, thanks.