[SPLIT_MODULE] Fix wasmRawExports to actually be the raw exports. NFC

[sbc100]

We don't want the raw exports include things like
Asyncify.instrumentWasmExports or relocateExports. They should be the actual raw exports.

See #25621

[tlively]

Is there a test we can write for this?

[inolen]

It would also be useful to not have this behind the SPLIT_MODULE ifdef (at least for my personal use).

[sbc100]

It would also be useful to not have this behind the SPLIT_MODULE ifdef (at least for my personal use).

Sadly that would increase codesize for everyone so we don't want to do that by default if we can help it.

Have you looked into using wasmImport + -sMAIN_MODULE=2 (that latter will inject raw exports that you want into wasmImports on load).

[sbc100]

Is there a test we can write for this?

Its a little tricky because for a couple of reasons:

1. We would need to make the test sensitive to having JS wrapper around the imports.
2. We would need to make sure the imports we split out have some kind of JS wrapper installed.

I will have a go but if its not easy I might just request that we land this as a "does not regress" change :)

[kripken]

I don't feel strongly either way about testing here.

[inolen]

It would also be useful to not have this behind the SPLIT_MODULE ifdef (at least for my personal use).

Sadly that would increase codesize for everyone so we don't want to do that by default if we can help it.

Have you looked into using wasmImport + -sMAIN_MODULE=2 (that latter will inject raw exports that you want into wasmImports on load).

I think I'm worried about MAIN_MODULE having side effects going that route. Grepping in src/ yields ~60 conditionals that have to do with that. So yes, accessing wasmImports would be stable that way, but there's a lot of other potential side effects.

What exactly is the problem with always defining? Is it the few extra bytes from it uselessly existing there for 99.9% of people, or does it existing cause some other chain of events with a more significant impact on the overall size?

[sbc100]

It would also be useful to not have this behind the SPLIT_MODULE ifdef (at least for my personal use).

Sadly that would increase codesize for everyone so we don't want to do that by default if we can help it.
Have you looked into using wasmImport + -sMAIN_MODULE=2 (that latter will inject raw exports that you want into wasmImports on load).

I think I'm worried about MAIN_MODULE having side effects going that route. Grepping in src/ yields ~60 conditionals that have to do with that. So yes, accessing wasmImports would be stable that way, but there's a lot of other potential side effects.

I made some changes recently that make the cost of -sMAIN_MODULE=2 almost zero. It would be great if you could give it a try.

What exactly is the problem with always defining? Is it the few extra bytes from it uselessly existing there for 99.9% of people, or does it existing cause some other chain of events with a more significant impact on the overall size?

No, the codesize cost is just a few bytes for everyone. Emscripten tries to avoid these kind of things because we suffer from a death by a thousand cuts if we are not careful. In this case though I'm also worried about exposing more internals and adding more things we need to test.

[inolen]

No, the codesize cost is just a few bytes for everyone. Emscripten tries to avoid these kind of things because we suffer from a death by a thousand cuts if we are not careful. In this case though I'm also worried about exposing more internals and adding more things we need to test.

Totally understood re: death by a thousand cuts.

Just tested with MAIN_MODULE=2 and using wasmImports - it worked. The downsides however -
1.) accessing something called imports to get exports and
2.) it made the file about 3% larger. if that's not expected, i can take a look to see what extra is getting added in

[sbc100]

1.) accessing something called imports to get exports and

I guess it kind of makes sense because this is the object that you will pass as the "imports" object to each wasm file you instantiate right?

This object acts as a kind of global symbol table for dynanic linking. Each wasm module imports it and the exports of each module as then added to it. Maybe we could rename it something better? "globalSymbolTable", "objectToImportIntoWasmFiles"?

2.) it made the file about 3% larger. if that's not expected, i can take a look to see what extra is getting added in

3% seems like about what I expected. Is the coming from increased Wasm or JS size BTW?

[sbc100]

I'm gonna land this PR now and we can continue the discussion in followups.

[inolen]

Don't worry, I'm not sweating it right now. 3% doesn't matter here, and there are more pressing things to work on :)