Stage2: wasm-linker - Only export symbols notated as such

[Luukdegram]

This exposes a function from stage2 to stage1 to append symbols to automatically export them.
Stage1 will only call this function when the target is wasm.

The linker will then only append --export=<symbol> for when the user has not done so manually and did not provide the -rdynamic flag also. This allows the user to still override the default behavior do they wish to.

I also went ahead and implemented the same behavior for the LLVM backend when using stage2, meaning we can remove all stage1 related code for this without losing the behavior when stage2 becomes the default compiler.

Closes #2910
Closes #7133

[Luukdegram]

This is interesting. The error in the CI actually only happens when using wasmtime, where as wasmer executes the tests perfectly. For some reason, wasmtime assume an exported u32 global is a function. (wasm-objdump correctly shows it as a global, that points to the symbol's value in the data section).
I'll investigate more tomorrow and create an issue downstream if it's indeed a bug on their end.

[kubkon]

This is interesting. The error in the CI actually only happens when using wasmtime, where as wasmer executes the tests perfectly. For some reason, wasmtime assume an exported u32 global is a function. (wasm-objdump correctly shows it as a global, that points to the symbol's value in the data section). I'll investigate more tomorrow and create an issue downstream if it's indeed a bug on their end.

Note that this very well may be a bug with Wasmtime. Great job btw!

[andrewrk]

Should we switch to wasmer in the CI, or perhaps upgrade to a newer wasmtime version?

[Luukdegram]

It appears that under the current WASI application ABI, instances may assume exports are not accessed when using the command execution model. This is exactly the model we use when running tests. Wasmer seems to simply ignore unexpected exports, whereas wasmtime is a bit more strict about it and errors. (There's a flag --allow-unknown-exports available to allow those).

Here's how I think we should solve it for now:
Append the --allow-unknown-exports flag to wasmtime, and revisit this flag when stage2 becomes the default compiler. (As we will have much more information about the export decls, as well as the execution model we're using).

[kubkon]

Sounds reasonable to me!

[andrewrk]

Nice work! Just need an additional cache input and then this is good to go.

[andrewrk]

After making the previous review, I realized my suggestion about the cache hash is incorrect, since export_symbol_names depends only on the source files and cannot be overridden by CLI args.

This is good to merge.

[andrewrk]

The Windows failure does look potentially relevant. The failing test is using the wasm32-wasi target.

[Luukdegram]

The Windows failure does look potentially relevant. The failing test is using the wasm32-wasi target.

Failure definitely seems to be related to this change, as it is reproducible on the CI. However, I fail to see why this is happening on Windows only. I'll see if I can rent out some cheap Windows VM as I don't own any Windows machine nor have the RAM to run a VM that hosts Windows and is able to build the compiler. Will need some more time to get this PR ready, but we'll get there!

[Luukdegram]

Interestingly, commenting out the call to stage2_append_symbol does make the test cases for Windows succeed. This makes me think it may be some ABI issue, tho the function definition does seem alright.

[kubkon]

@Luukdegram I got my local Win10 installation setup for development today so can have a look at this failure tomorrow. Will keep you posted!