You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We were using the sign bit of an integer to distinguish between data
pointers and fixed JS function indexes, but that doesn't work once
that data address can be larger than 2^31.
Technically this is very unlikely in practice since in order to get
an EM_ASM address over 2^31 you would either need 2Gb of static data
to be using `-sGLOBAL_BASE=2gb` like we do in the tests.
An alternative approach here would be assume we have fewer than
`GLOBAL_BASE` (1024 is most cases) proxied JS library functions and then
we could assume that small integers we JS library functions and larger
ones were data pointers (EM_ASM functions). However that seems fragile
too. Passing an extra argument around seems like a small cost here.
// of using __proxy. (And dor simplicity, do the same in the sync
2910
2910
// case as well, even though it's not strictly necessary, to keep the two
2911
2911
// code paths as similar as possible on both sides.)
2912
-
// -1 - code is the encoding of a proxied EM_ASM, as a negative number
2913
-
// (positive numbers are non-EM_ASM calls).
2914
-
returnproxyToMainThread(-1-code,sync, ...args);
2912
+
returnproxyToMainThread(0,codePtr,sync, ...args);
2915
2913
}
2916
2914
#endif
2917
2915
#if ASSERTIONS
2918
-
assert(ASM_CONSTS.hasOwnProperty(code),`No EM_ASM constant found at address ${code}. The loaded WebAssembly file is likely out of sync with the generated JavaScript.`);
2916
+
assert(ASM_CONSTS.hasOwnProperty(codePtr),`No EM_ASM constant found at address ${codePtr}. The loaded WebAssembly file is likely out of sync with the generated JavaScript.`);
0 commit comments