This is a work-in-progress to get things enabled. The main bulk of the
change here is updating LLVM itself to tip-of-tree as of yesterday
morning. This removes two `*.patch` files because they've landed, and
adds another `*.patch` file to work around a new issue that's cropped
up. I've also included a `*.patch` for
https://github.com/llvm/llvm-project/pull/200855, too.
This isn't ready yet to land as it's still failing to build/link/etc,
and I'll comment some more below.
These are now named `wasm32-wasip1` and `wasm32-wasip1-threads`. The
previous targets take time to build in CI and space in the distribution,
and clang is warning about their usage. Remove them now that the warning
has been around for a bit.
Adds a new CMake option, defaulting to `ON` so existing builds are
unaffected. When set to `OFF`, `wasi-libc` is built with
`-DBUILD_SHARED=OFF` (its existing `if (NOT BUILD_SHARED)` block then
short-circuits the per-target `set(SHARED ON)` for
`wasm32-wasi`/`wasm32-wasip1`), and the `libcxx`/`libcxxabi`/`libunwind`
invocations no longer use `${pic}` directly for their `*_ENABLE_SHARED`
flags — they go through a new local `shared` variable that AND's
`WASI_SDK_BUILD_SHARED` with `${pic}`.
Motivation: downstream consumers that build wasi-sdk from source as part
of a larger toolchain pipeline (in our case, Firefox's build system)
don't ship or link against shared sysroot artifacts. The current code
path provides no way to opt out, so we've been patching locally. The
existing comment in `wasi-sdk-sysroot.cmake` notes shared libraries
aren't supported with LTO; this doesn't change that default, it just
exposes the same toggle for non-LTO builds too.
A `static` entry is added to the `build-only-sysroot` CI matrix to
exercise the OFF path.
This commit collects together some LLVM PRs, some changes in the build
configuration here, and some thoughts from #565 and related issues.
Specifically the changes here are:
* The patch for llvm/llvm-project#168449 is updated to its upstream
(unlanded) form.
* Patches for the (landed) llvm/llvm-project#185770 and
llvm/llvm-project#185775 are added.
* The `WASI_SDK_EXCEPTIONS` configuration is now either `ON`, `OFF`, or
`DUAL`. The default depends on the version of Clang in use, where
23.0.0+ (which isn't released officially yet) will be `DUAL` and
otherwise it's `OFF`. CI for our custom-built patched toolchain defaults
to `DUAL`.
* In `DUAL` mode libcxx is built twice into two different directories,
once with exceptions and once without. This is supported by LLVM patches
and means that Clang will select the right set of libraries based on
compiler flags.
The end result here is that the produced toolchain from this repository,
by default, supports C++ exceptions. Additionally if exceptions-related
flags are not passed then the final binary will not use C++ exceptions
nor require the wasm exception-handling proposal.
There's still follow-up work from #565, such as:
* Subjectively it feels wordy to pass `-fwasm-exceptions` vs
`-fexceptions`.
* Personally I think `-mllvm -wasm-use-legacy-eh=false` should become
the default upstream.
* Subjectively I don't think that `-lunwind` should be necessary and it
should be injected automatically with `-fwasm-exceptions` (or
`-fexceptions`).
* Shared libraries for exceptions remain disabled due to build errors I
do not personally know how to resolve.
I'll file follow-up issues for these once this has landed since they're
more minor compared to the main body of "anything works".
Closes#334Closes#565
---------
Co-authored-by: Joel Dice <joel.dice@akamai.com>
No longer use `wasm32-wasi` since Clang issues a deprecation warning
about that. This fixes the `clang` binary, by default, emitting a
warning for example in the final build.
This is intended to provide a known-good build of LLDB with wasm plugin
support which can exist alongside the rest of the LLVM distribution
provided by wasi-sdk.
This includes a new library, `libclang.so`, which is Clang's public C
API. This is used by tooling such as Rust's `bindgen` library to
generate bindings and can be useful when bindings are generated using a
wasi-sdk distribution.
Build `wasip3` target
~Requires #592~
There's a lot of failing tests currently, so we'll probably want to
rebase this PR as we pull in more recent versions of `wasi-libc` and
merge once tests pass
---------
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
> **Note**: this PR is me weaving together the work of many others. For
example @yerzham's and @cpetig's work on #565 pretty much shaped this
PR. Thank you!
This commit adds initial configuration support for building wasi-sdk
with support for C++ exceptions in WebAssembly. A small test is included
which is exercised in CI at this time, but otherwise this does not
update CI to actually ship sdk builds with C++ exceptions enabled.
Instead the intention here is to make it easier to test builds with
support for C++ exceptions and centralize planning/development around
this.
The goal here is to get things compiling to the point that applications
can be compiled. I haven't thoroughly tested C++ exceptions and as
evident in this PR it still requires changes in LLVM. Some small logic
is added here to apply a `*.patch` file to LLVM to avoid needing a new
submodule fork or waiting for upstream changes. The intention is that
this `*.patch` is short-lived once the changes are officially merged
into LLVM itself.
The `*.patch` included here contains llvm/llvm-project#168449 as well as
another minor edit I found was necessary to get things compiling
locally. Given the discussion on that PR it looks like once LLVM is
updated with that merged the extra part of the `*.patch` won't be
necessary.
This PR notably does not enable shared libraries when exceptions are
enabled. I don't know enough about how things are supposed to work to be
able to fully diagnose the compilation errors I'm seeing if shared
libraries are enabled. This is something I'd hope would be fixed before
actually shipping exceptions support.
This PR then additionally folds in [this gist][gist] for various bits of
build logic to this repository itself.
Finally, this PR includes some documentation about the current status of
exceptions and links to various tracking issues too.
[gist]: https://gist.github.com/yerzham/302efcec6a2e82c1e8de4aed576ea29d
This updates to include WebAssembly/wasi-libc#709 and then additionally
configures wasi-libc with `-DWASI_SDK_VERSION=...` to ensure that
wasi-sdk builds will now have `__wasi_sdk_major__` defined along with
`__wasi_sdk_version__`.
ClosesWebAssembly/wasi-libc#688
This commit updates the build of the `wasm32-wasip2` target to always
pass `-fPIC` to compilation of wasi-libc. This notably enables using
`libc.a` in dynamic linking situations instead of being forced to use
`libc.so`. While many applications likely want to use `libc.so` I've
found it more flexible if objects are compatible with as many builds as
possible. This will enable, for example, building shared libraries in
Rust by default since Rust only ships `libc.a`, not `libc.so`, in the
pre-built sysroot. This behavior additionally matches the Rust
`wasm32-wasip2` target where `-fPIC` is enabled by default there.
Add a cmake option WASI_SDK_CPU_CFLAGS to specify CFLAGS to control wasm
features to enable/disable.
Make the default `-mcpu=lime1`.
Comparing to the default "generic" target of the recent llvm, this
effectively
* disables reference-types and bulk-memory (enable their partial
counterparts instead)
* enables extended-const
Note: as of writing this, a few popular runtimes, including wasm3 and
wasm-micro-runtime,
don't support extented-const yet.
Note: regardless of this, wasi-libc enables necessary features for
certain files. (bulk-memory and exception-handling)
cf. https://github.com/WebAssembly/wasi-sdk/issues/525
References:
https://github.com/WebAssembly/tool-conventions/blob/main/Lime.mdhttps://github.com/bytecodealliance/wasm-micro-runtime/issues/4272
This commit enables thread support in libc++ for all thread models,
enabling C++ applications that use threading APIs like `<atomic>` but do
not spawn threads (e.g. Clang) to be built with minimal changes.
Fixes#546.
Depends on WebAssembly/wasi-libc#602.
This change allows us to have per-target libclang_rt.* libraries instead
of per-OS. This is particularly required for w/threads and wo/threads
targets, whose rt libraries could be incompatible even with the same OS
string.
This change starts building `compiler-rt` for w/threads and wo/threads
separately, so that we can enable thread-related features for p1-threads
target for building upcoming ASan clang_rt libraries. Also
`COMPILER_RT_OS_DIR` is not set anymore as it's unused when
`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is enabled.
* Pin CI runner images to explicit versions
CI is run infrequently enough on this repository that there's a
nontrivial chance that GitHub updates the definition of `ubuntu-latest`
for example between two CI runs. This can be confusing for contributors
as PRs seemingly break CI when in reality they have nothing to do with
the breakage and it's due to the image changing.
This PR pins all images to the definition of `*-latest` at this time.
The one exception is that one builder was pinned to 22.04 and I'm going
to update it to 24.04 here and see if I can't fix CI issues that come up.
This'll require explicit PRs to update these images in the future, but
hopefully that's only once every few ~years so not too much of a burden.
* Try not custom-installing clang 18
* Try to fix CI issue
* Fix CI again (attempt)
* Further try to fix CI
* Another fix for CI
Surely if I keep making commits that say "another fix" eventually I'll
run out of fixes. Surely, right? I'd put this in limerick form to be
more amusing if someone comes to read this but I'm not clever enough to
do that, so instead I'll just abruptly
* Update wasm-component-ld
Pulls in a fix for bytecodealliance/wasmtime#10058 in the adapters that
are used by default.
* Update wasmtime installed in CI
* Downgrade the build-only-sysroot check step
Looks like this is failing on Ubuntu 24.04, the new default of
`ubuntu-latest`, so downgrade it to have it get fixed in a separate PR.
* Try downgrading Wasmtime version again
* Update base Linux images to Ubuntu 20.04
* Update Wasmtime back to 29
There is an option to compile debug information to separate file. It's supported in Clang via -gsplit-dwarf to generate dwo files but we need llvm-dwp tool to combine them into single dwp file supported by Chrome DWARF extension https://developer.chrome.com/blog/faster-wasm-debugging
* Add back `VERSION` file to release tarballs
Make sure it makes its way into the sysroot tarball and then copy it
from the sysroot location to the top of the sdk tarball as well.
Closes#471
* Fix how `VERSION` is installed
This commit adds a test and matrix entry to CI which asserts that the
sysroot can be built to run tests using a stock Clang compiler found on
the system. This fixes a few minor issues as well in developing this.
This additionally refactors CI a bit to move shared steps amongst jobs
into separate composite actions in this repository to avoid duplication
across jobs.
Alex Crichton
Ryan VanderMeulen
Daniel Nicoletti
Roman Volosatovs
Catherine
YAMAMOTO Takashi
Dan Gohman
Yuta Saito
Carlo Cabrera
Roman Kolesnikov
SingleAccretion