[clang][WebAssembly] support wasm32-wasi shared libraries

[dicej]

Summary

This adds support for Emscripten-style shared libraries [1] to the wasm32-wasi
target. Previously, only static linking was supported, and the -shared and
-fPIC flags were simply ignored. Now both flags are honored.

Since WASI runtimes do not necessarily include JavaScript support, we cannot
rely on the JS-based Emscripten linker to link shared libraries. Instead, we
link them using the Component Model proposal [2].

We have prototyped shared library support in wasi-sdk [3] and put together a
demo [4] which uses a patched version of wit-component [5] to link libraries
using the Component Model. We plan to submit the required changes upstream to
the respective repositories in the next week or two.

[1] https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md
[2] https://github.com/WebAssembly/component-model/blob/main/design/mvp/examples/SharedEverythingDynamicLinking.md
[3] https://github.com/dicej/wasi-sdk/tree/dynamic-linking
[4] https://github.com/dicej/component-linking-demo
[5] https://github.com/bytecodealliance/wasm-tools/tree/main/crates/wit-component

Signed-off-by: Joel Dice <[e-mail]>

[sbc100]

Nice! lgtm with a couple of nits

clang/docs/ReleaseNotes.rst

705

Would it not make more sense to simply say that all WebAssembly targets now support shared libraries and PIC code generation? Perhaps we could phrase it something like this:

"Shared library support (and PIC code generation) for is no longer limited to the Emscripten target OS and now works with other targets such as wasm32-wasi."

clang/test/Driver/wasm-toolchain.c

38

Perhaps this part could be enerat

63

The test above say with known OS.. which is perhaps more appropriate here.

Also, shouldn't all these also work (and be tested with) unknown OS?

llvm/utils/lit/lit/llvm/config.py

347 ↗

(On Diff #532688)

Are the the changes to this file meant to be part of this CL?

[dicej]

Thanks for the review. I'll post an update shortly.

clang/docs/ReleaseNotes.rst

705

Agreed! I'll update it.

clang/test/Driver/wasm-toolchain.c

38

Sorry, I'm having trouble parsing this; did your comment get cut off?

63

Sounds reasonable. I'll edit the comment and add tests for the unknown case.

llvm/utils/lit/lit/llvm/config.py

347 ↗

(On Diff #532688)

The check-clang target doesn't work at all if the target "triple" is a double, e.g.:

llvm-lit: /Users/dicej/p/wasi-sdk/src/llvm-project/llvm/utils/lit/lit/llvm/config.py:459: note: using clang: /Users/dicej/p/wasi-sdk/build/llvm/bin/clang
llvm-lit: /Users/dicej/p/wasi-sdk/src/llvm-project/llvm/utils/lit/lit/llvm/config.py:324: fatal: Could not turn 'wasm32-wasi' into Itanium ABI triple

@sunfish had been using this patch locally to work around the issue, so I figured I'd include the patch here so it stops being a stumbling block. Perhaps there's a better way to address it?

[dicej]

generalize Wasm tests and release notes

[sbc100]

lgtm.

[dicej]

@sbc100 Thanks for the "lgtm". What's the next step to get this merged?

[sbc100]

I'm happy to merge it, but perhaps we should get @sunfish to lg too.

Also, should we remove the -experimental-pic linker flag, or are you OK with that warning from the linker? If yes, I wonder if we should do that as part of this CL or a followup?

[sunfish]

This patch appears to be just the release notes and the test; is the actual driver change missing?

clang/docs/ReleaseNotes.rst

706

We should mention that this format is not yet stable and may change between LLVM versions, and that WASI does not yet have any facilities for loading dynamic libraries.

[dicej]

In D153293#4437583, @sunfish wrote:

This patch appears to be just the release notes and the test; is the actual driver change missing?

Sorry -- this is the first time I've used arc, and I apparently messed up. I meant to add an extra commit on top of the original, but it just replaced the original. I'll combine them and expand the release notes per your comment.

[dicej]

In D153293#4436629, @sbc100 wrote:

I'm happy to merge it, but perhaps we should get @sunfish to lg too.

Also, should we remove the -experimental-pic linker flag, or are you OK with that warning from the linker? If yes, I wonder if we should do that as part of this CL or a followup?

Do emscripten users see that warning, too? I'd like to match whatever they see (or don't see).

[dicej]

update release notes

[sbc100]

In D153293#4437644, @dicej wrote:

In D153293#4436629, @sbc100 wrote:

I'm happy to merge it, but perhaps we should get @sunfish to lg too.

Also, should we remove the -experimental-pic linker flag, or are you OK with that warning from the linker? If yes, I wonder if we should do that as part of this CL or a followup?

Do emscripten users see that warning, too? I'd like to match whatever they see (or don't see).

No, the emscripten driver (emcc) currently adds --experimental-pic to the linker flags to avoid this warning. We could gladly remove that if it becomes the default.

[dicej]

In D153293#4437877, @sbc100 wrote:

In D153293#4437644, @dicej wrote:

In D153293#4436629, @sbc100 wrote:

I'm happy to merge it, but perhaps we should get @sunfish to lg too.

Also, should we remove the -experimental-pic linker flag, or are you OK with that warning from the linker? If yes, I wonder if we should do that as part of this CL or a followup?

Do emscripten users see that warning, too? I'd like to match whatever they see (or don't see).

No, the emscripten driver (emcc) currently adds --experimental-pic to the linker flags to avoid this warning. We could gladly remove that if it becomes the default.

OK; I'd say let's leave the warning there since this feature is so new for non-emscripten targets. We can come back and remove it later on once things have settled.

[sbc100]

llvm/utils/lit/lit/llvm/config.py

347 ↗

(On Diff #532688)

Can you split this out into a separate change.. its seem unrelated.

[dicej]

remove config.py changes per review feedback

[dicej]

@sbc100 @sunfish I believe I've addressed all your feedback so far. Anything else you'd like me to do before we call this ready?

clang/docs/ReleaseNotes.rst

- Introduced the ``-mxcoff-roptr`` option to place constant objects with
   relocatable address values in the read-only data section. This option should
   be used with the ``-fdata-sections`` option, and is not supported with
   ``-fno-data-sections``. When ``-mxcoff-roptr`` is in effect at link time,
   read-only data sections with relocatable address values that resolve to
   imported symbols are made writable.
 
 WebAssembly Support
 ^^^^^^^^^^^^^^^^^^^
-- The `wasm32-wasi` target now supports `Emscripten-style shared libraries
-  <https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md>`_.
+- Shared library support (and PIC code generation) for WebAssembly is no longer
+  limited to the Emscripten target OS and now works with other targets such as
+  wasm32-wasi.
 
 AVR Support
 ^^^^^^^^^^^
 - The definition of ``USHRT_MAX`` in the freestanding ``<limits.h>`` no longer
   overflows on AVR (where ``sizeof(int) == sizeof(unsigned short)``).  The type
   of ``USHRT_MAX`` is now ``unsigned int`` instead of ``int``, as required by
   the C standard.
 

clang/test/Driver/wasm-toolchain.c

 
 // A basic C link command-line with known OS.
 
 // RUN: %clang -### --target=wasm32-wasi --sysroot=/foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=LINK_KNOWN %s
 // LINK_KNOWN: "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-wasi" "crt1.o" "[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
-// -shared should be passed through to `wasm-ld` and not include crt1.o
+// -shared should be passed through to `wasm-ld` and not include crt1.o with a known OS.
 
 // RUN: %clang -### -shared --target=wasm32-wasi --sysroot=/foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=LINK_KNOWN_SHARED %s
 // LINK_KNOWN_SHARED: "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_KNOWN_SHARED: wasm-ld{{.*}}" "-L/foo/lib/wasm32-wasi" "-shared" "[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
+// -shared should be passed through to `wasm-ld` and not include crt1.o with an unknown OS.
+
+// RUN: %clang -### -shared --target=wasm32-unknown-unknown --sysroot=/foo %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=LINK_UNKNOWN_SHARED %s
+// LINK_UNKNOWN_SHARED: "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
+// LINK_UNKNOWN_SHARED: wasm-ld{{.*}}" "-shared" "[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
+
 // A basic C link command-line with optimization with known OS.
 
 // RUN: %clang -### -O2 --target=wasm32-wasi --sysroot=/foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=LINK_OPT_KNOWN %s
 // LINK_OPT_KNOWN: "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_OPT_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-wasi" "crt1.o" "[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C compile command-line with known OS.
 
 // RUN: %clang -### --target=wasm32-wasi --sysroot=/foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=COMPILE %s
 // COMPILE: "-cc1" {{.*}} "-internal-isystem" "/foo/include/wasm32-wasi" "-internal-isystem" "/foo/include"
 
-// -fPIC should work for WASI
+// -fPIC should work on a known OS
 
 // RUN: %clang -### -fPIC --target=wasm32-wasi --sysroot=/foo %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=COMPILE_PIC %s
-// COMPILE_PIC: "-cc1" {{.*}} "-mrelocation-model" "pic" "-pic-level" "2" {{.*}} "-internal-isystem" "/foo/include/wasm32-wasi" "-internal-isystem" "/foo/include"
+// RUN:   | FileCheck -check-prefix=COMPILE_KNOWN_PIC %s
+// COMPILE_KNOWN_PIC: "-cc1" {{.*}} "-mrelocation-model" "pic" "-pic-level" "2" {{.*}} "-internal-isystem" "/foo/include/wasm32-wasi" "-internal-isystem" "/foo/include"
+
+// -fPIC should work on an unknown OS
+
+// RUN: %clang -### -fPIC --target=wasm32-unknown-unknown --sysroot=/foo %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=COMPILE_UNKNOWN_PIC %s
+// COMPILE_UNKNOWN_PIC: "-cc1" {{.*}} "-mrelocation-model" "pic" "-pic-level" "2"
 
 // Thread-related command line tests.
 
 // '-pthread' sets +atomics, +bulk-memory, +mutable-globals, +sign-ext, and --shared-memory
 // RUN: %clang -### --target=wasm32-unknown-unknown \
 // RUN:    --sysroot=/foo %s -fuse-ld=wasm-ld -pthread 2>&1 \
 // RUN:  | FileCheck -check-prefix=PTHREAD %s
 // PTHREAD: "-cc1" {{.*}} "-target-feature" "+atomics" "-target-feature" "+bulk-memory" "-target-feature" "+mutable-globals" "-target-feature" "+sign-ext"