OK, what I want to do isn't possible in Emscripten.
Thanks, everyone.
John
On Tue, Sep 9, 2025 at 7:37 AM Heejin Ahn <ahee...@gmail.com> wrote:
> Correct. Both Emscripten and Wasm SjLj handling requires the setjmp point
> to be "lower" than the longjmp point, because both use exceptions to
> simulate setjmp-longjmp.
> So this works:
> ```
> static jmp_buf buf;
>
> void bar() {
> }
>
> int main() {
> int jmpval = setjmp(buf);
> if (jmpval == 0) {
> printf("first call\n");
> } else {
> printf("second call\n");
> exit(0);
> }
> bar();
> return 0;
> }
> ```
>
> But this does NOT work:
> ```
> static jmp_buf buf;
>
> void foo() {
> int jmpval = setjmp(buf);
> if (jmpval == 0) {
> printf("first call\n");
> } else {
> printf("second call\n");
> exit(0);
> }
> }
>
> void bar() {
> longjmp(buf, 1);
> }
>
> int main() {
> foo();
> bar();
> return 0;
> }
> ```
>
> Because by the time longjmp is called, foo's call stack has been destroyed.
>
> On Mon, Sep 8, 2025 at 4:31 PM 'Sam Clegg' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> If you want to use `longjmp` in emscripten to get back to start of the
>> failing test, we have two setjmp/longjmp mechanism. (1) The old emscripten
>> method (2) The method using wasm exception handling.
>>
>> However, I believe that in both cases the target of the long jump has to
>> be above the caller on the stack. That is, once you unwind the stack all
>> of the way it will no longer be possible to `longjmp` to the target in
>> question since its no longer on the stack. @Heejin Ahn
>> <ahee...@google.com> can you confirm this?
>>
>> If that is correct then you will need to some kind of alternative
>> mechanism when running in emscrpten. Something like this maybe:
>>
>> ```
>> void run_death_test(death_test_fn_t fn) {
>> #ifdef __EMSCRIPTEN__
>> EM_ASM({
>> try {
>> ...call_fn_from_js..
>> report_failure_to_die()
>> } catch (e) {
>> report_success_if_e_looks_good(e)
>> }
>> })
>> #else
>> setup_longjmp_target():
>> fn();
>> #endif
>> }
>> ```
>>
>> On Mon, Sep 8, 2025 at 4:17 PM Sam Clegg <s...@google.com> wrote:
>>
>>>
>>>
>>> On Mon, Sep 8, 2025 at 3:40 AM John Dallman <jgdatsiem...@gmail.com>
>>> wrote:
>>>
>>>> > Is the test harness and the library-under-test designed to be
>>>> compiled into the
>>>> > same executable?
>>>>
>>>> Yes. We prefer to have the library-under-test be a shared object or
>>>> Windows DLL, on platforms where that's possible, but we can have the
>>>> harness and the library linked together, and that's what I'm planning to do
>>>> for WebAssembly. I'm trying to avoid producing a JS wrapper for an API with
>>>> hundreds of functions, hundreds of structs, and thousands of constants. It
>>>> also passes lots of pointers to code and data through the interface. My
>>>> customers who want a WebAssembly version of the library already have C/C++
>>>> or Swift code that calls it and want to use it that way.
>>>>
>>>> > i.e. on other platforms does it somehow catch and recover from
>>>> sefaults?
>>>>
>>>> Yes.On platforms with signals, those are turned on for segmentation
>>>> faults (and for some other signals, depending on the platform). The code is
>>>> C, which sets regular checkpoints with setjmp() and the signal handling
>>>> function longjmp()s to the latest checkpoint with a "test aborted" value.
>>>> That's the basic idea, though it's rather more complicated in practice.
>>>>
>>>
>>> Oh wow, `longjmp` out of your signal handler sounds pretty gnarly.
>>> It's going to be even more gnarly trying to make that work with
>>> emscripten-generated code, but maybe not impossible?
>>>
>>> Are there segfault tests limited in number? i.e. would it be possible
>>> to choose a different approach when running on the web (just for these few
>>> tests)?
>>>
>>>>
>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29WgYahkgoafxhXGs%2BPhfpP-o6GzQSgaTA3xRGhdPKRNg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29WgYahkgoafxhXGs%2BPhfpP-o6GzQSgaTA3xRGhdPKRNg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/emscripten-discuss/CALJpS1Nzcxx0mzS%2BxHTxrETvyGiuppeOcz68PNdjwNtYaG0YcA%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CALJpS1Nzcxx0mzS%2BxHTxrETvyGiuppeOcz68PNdjwNtYaG0YcA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgnni_-DvpsAxNFV0Aac8hGgz5m6Yo-bxkDsFP_kzdPpDw%40mail.gmail.com.
