SDL2 image code somehow implicitly enables Wasm Exnref EH

[juj]

test.c

#include <SDL2/SDL_image.h>
int main() { IMG_Load(""); }

Build with

emcc test.c -sSUPPORT_LONGJMP=wasm -sUSE_SDL_IMAGE=2 -sSDL2_IMAGE_FORMATS=png -o a.html

The resulting file will have a Wasm Tag section, and the resulting file cannot be run in browsers that do not support Wasm Exnref exception handling.

(My understanding is that Tag section did not exist yet for the Wasm Legacy EH, is that right?)

Does -sSUPPORT_LONGJMP=wasm imply Wasm Exnref exception handling support? I am confused if it does, since Emscripten names Wasm Exnref exceptions as just "Wasm EH", and it is ambiguous with previous Wasm exception handling, now called Wasm Legacy EH.

Somehow SDL2_image with PNG support is leaking in a requirement of Wasm Exnref EH, and I'm not sure where it comes from.

This can be seen for example in browser tests

browser.test_sdl2_image_formats_wasm_legacy_wasmfs
browser.test_sdl2_image_formats_wasm_legacy

failing in browsers that do not support Wasm Exnref, because these tests are actually using Wasm Exnref support, and not Wasm Legacy EH.

(Seen when attempting to run browser suite in Firefox 102.15.1esr which did not yet support Wasm Exnref EH) Err, I had a mistake here. Firefox 102.15.1esr actually works, but it was the one version earlier that didn't, so:

(Seen when attempting to run browser suite in Firefox 91.13.0esr which did not yet support Wasm Exnref EH)

[sbc100]

I think that tag sections exists in both Wasm EH modes. Tags are IIUC always needed to match which types of exceptions you want to catch.

The difference between the two modes is IIUC, not the whether tags exists, but in whether or not you can refer to exceptions at runtime as a first class value with their own type (exnref).

[sbc100]

Does -sSUPPORT_LONGJMP=wasm imply Wasm Exnref exception handling support?

No as far as I know the only option to enable enxref exception handling is -sWASM_LEGACY_EXCEPTIONS=0, and this setting is on by default, and is not turned off implicitly anywhere, or my any other settings (IIUC).

[juj]

Gotcha. Though presumably those two _wasm_legacy browser tests should work in Firefox 100 Fireofx 91.13.0esr that didn't still support Wasm Exnref EH? Those are the only two tests in the browser suite that do not work in Firefox 91.13.0esr, and the issue is that Firefox refuses to parse the Wasm Module because it has a Tag section in it. (or maybe some contents in the tag section are unexpected?)

[juj]

Something in the repro is enabling Wasm Exnref EH, that is.

[sbc100]

do not work in Firefox 100, and the issue is that Firefox refuses to parse the Wasm Module because it has a Tag section in it. (or maybe some contents in the tag section are unexpected?)

What is the actual error you are seeing? Does it specifically mention the tag section as being the problem? Do you happen to know what spidermonkey version is used in Firefox 100?

[juj]

Btw, why do some ports manipulate exception handling, but not others?

I would expect either all ports to have to, or no ports to have modifications to those settings?

[sbc100]

I would expect that only the ports that actually use setjmp/longjmp (or have dependencies that use setjmp/longjmp) have these flags.

As far as I know no ports use actual C++ exceptions, they only use them for the purpose of setjmp/longjmp.

[juj]

The error I am seeing is

with the .wasm file having:

i.e. Firefox is croaking on seeing the Tag section.

[juj]

Err, I was confused by version numbers in above.

So the above error occurs in Firefox 91.13.0esr, which does not have Wasm Exnref EH support. The error itself is expected for code that does not have Wasm Exnref EH support.

The code works in the next esr: Firefox 102.15.1esr. We are not debugging/troubleshooting Firefox behavior here. (as far as I can see)

The surprise here is that the tests

browser.test_sdl2_image_formats_wasm_legacy_wasmfs
browser.test_sdl2_image_formats_wasm_legacy

are causing this error in Firefox 91.13.0esr. These tests have the name "wasm_legacy" in the tests, which suggests that these tests should be exercising Legacy Wasm EH, and not Wasm Exnref EH.

But it looks like these two tests are instead exercising Wasm Exnref EH and not Legacy Wasm EH.

[juj]

Oh wait, I'm being stupid. The Legacy Wasm EH was introduced to Firefox in version 100 only. So Firefox 91 cannot do Wasm Exnref EH, but it also cannot do Wasm Legacy EH either...

Closing as invalid.

[juj]

So I suppose that passing -sSUPPORT_LONGJMP=wasm will implicitly enable one of Wasm Legacy EH, or Wasm Exnref EH, and whichever will end up being activated depends on the value of -sWASM_LEGACY_EXCEPTIONS? (by default Wasm Legacy EH?)

[sbc100]

So I suppose that passing -sSUPPORT_LONGJMP=wasm will implicitly enable one of Wasm Legacy EH, or Wasm Exnref EH, and whichever will end up being activated depends on the value of -sWASM_LEGACY_EXCEPTIONS? (by default Wasm Legacy EH?)

Yes, IIUC, -sSUPPORT_LONGJMP=wasm will mean you depend on legacy wasm EH today.

If you disable legacy exceptions using -sWASM_LEGACY_EXCEPTIONS=0 then you will get enxref instead.

[juj]

Yeh, that matches what I was seeing. I updated the feature matrix PR c003d0c to match this behavior.