wasm: do not default to pic and re-enable tests

[Luukdegram]

For WebAssembly we want DynamicNoPIC for relocation mode. PIC is experimental, but will also force a shared library for WebAssembly which is not what the user expects as that will require runtime relocations to be performed.
This also re-enables the linker tests that regressed with llvm17

Closes #16937
Closes #16938

#16938 mentions:

Note that this test actually does not use LLVM or LLD:

The linker test verifies being able to link with an archive file. Since the Zig toolchain doesn't have an ar implementation yet, the test depends on compiler_rt, which is generated by LLVM. Due to LLVM17 actually supporting outputting PIC for WebAssembly, it generates a bunch of sections and relocations the in-house linker hasn't implemented yet. (Unfortunately, the stack trace is 💩 due to a double close to the file handle, which will be fixed in a separate PR).

[andrewrk]

Thanks!

[andrewrk]

PIC is experimental, but will also force a shared library for WebAssembly which is not what the user expects as that will require runtime relocations to be performed

if link_mode is "dynamic" then that's exactly what is being requested. Instead, link_mode should be set to static earlier on. I'll try to figure out why link_mode is being incorrectly set to Dynamic.

[andrewrk]

hmmm for compiler_rt specifically, we're passing static:

zig/src/Compilation.zig

Line 5487 in dd6a9ca

.link_mode = .Static,

[andrewrk]

OK the reason that link_mode is being set to Dynamic is because the tests are literally asking for it:

    const lib = b.addSharedLibrary(.{

force a shared library

that's exactly what's being asked for in the build.zig script.

[Luukdegram]

OK the reason that link_mode is being set to Dynamic is because the tests are literally asking for it:

    const lib = b.addSharedLibrary(.{

force a shared library

that's exactly what's being asked for in the build.zig script.

You're completely right, but we're currently in this odd position where users really just want a singular Wasm binary that's static and doesn't have an entry point but doesn't want an archive file (so don't build a static library). Perhaps we should instead use build-exe/addExecutable and use -no-entry, just like other compilers such as Clang and Rust do. For context, in #8857 the original behavior was changed by Jakub and users have to use -dynamic to build a loadable WebAssembly module. However, WebAssemly does in fact have a concept of dynamic libraries now, which is not what the test wants to build. There's currently (in llvm17 branch) no way to express a single static Wasm binary that can be loaded into a runtime/browser but does not have an entry point.

edit: In the near future we will want to support real dynamic libraries in the in-house linker also. For this, we'll need a way for the user to specify they want a dynamic library. It would make sense to have them use -dynamic to express that. So perhaps -fno-entry is the way to go.

[andrewrk]

I agree with your reasoning - build-exe with -fno-entry is the way to go. Also I think it's generally good to join in with Clang and Rust unless there is some really good reason to be different.

Apologies for the force push - I think that messed things up a bit here. Also, I'm perfectly willing to move forward with these tests disabled, including merging this branch into master when LLVM 17 is released. No need to rush on the fix. Let's solve this proper!

[Luukdegram]

No worries about the force push - Let's close this PR for now and I'll work on the proper fixes in a separate branch so the llvm17 work can get merged into master when ready. We can re-enable the linker tests in the branch with the proper fix in master later.