Move longjmp into native code - #14188
Conversation
This moves `longjmp` and `siglongjmp` into native code and leaves only the throwing stub in JS code, which cannot be moved. This currently fails a wasm2c test in `test_longjmp_standalone`. I don't know enough about wasm2c but it looks wasm2c has its own support in tools/wasm2c.py and tools/wasm2c/base.c. Any starting point on how to fix that part?
|
This was a part of #14108 and split into two parts. |
kripken
left a comment
There was a problem hiding this comment.
For the failing test, tools/wasm2c/base.c has an impl of Z_envZ_emscripten_longjmpZ_vii (emscripten_longjmp + wabt name mangling), which is used instead of the JS one. And now it will need to have an impl of the new _emscripten_throw_longjmp.
|
|
| # invoke calls, and they call setThrew(). We cannot handle this using | ||
| # deps_info as the invokes are not emitted because of library function | ||
| # usage, but by codegen itself. | ||
| '_setThrew', |
There was a problem hiding this comment.
I think the problem here is that you are introducing a new included-by-default function (since SUPPORT_LONGJMP defaults to 1).. so this will regress code size tests for tiny programs I believe. If a program never calls longjmp it should never need _setThrew... for exception handling the user has opted in so I more reasonable to accept that cost but most user don't explicitly opt into longjmp (they just get it because its the default).
There was a problem hiding this comment.
Removed it and added deps in deps_info.py instead with comments.
|
Indeed, it looks like a bunch of metadce tests are failing due to the new unconditional export. |
I think we should keep that test if we can.. presumably its a question of providing the right JS stub functions in the |
Made this work too. |
|
Sorry for the long delay. Hopefully all issues have been resolved now; PTAL. |
This moves
longjmpandsiglongjmpinto native code and leaves onlythe throwing stub in JS code, which cannot be moved. This makes code
simpler and makes all future wasm64-specific handling in JS side
unnecessary.
This currently fails a wasm2c test in
test_longjmp_standalone. I don'tknow enough about wasm2c but it looks wasm2c has its own support in
tools/wasm2c.py and tools/wasm2c/base.c. Any starting point on how to
fix that part?