Skip to content

[wasm] Toolchain support for wasm32-wali-linux-musl target #156087

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

[wasm] Toolchain support for wasm32-wali-linux-musl target #156087

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
cb996a1
Support for `wasm32-wali-linux-musl target` in `clang`, `lld`, and `l…
arjunr2 Aug 30, 2025
2d4f581
Added tests for wasm32 wali target compilation
arjunr2 Sep 2, 2025
f5cedb2
Add link to WALI ABI and fix unwind for sjlj non-wasm targets
arjunr2 Sep 4, 2025
a07eb13
Add newline
arjunr2 Sep 4, 2025
cfee54b
Merge branch 'main' into main
arjunr2 Sep 5, 2025
9985ce5
Merge branch 'main' into main
arjunr2 Sep 29, 2025
a0b8f5d
Merge branch 'main' into main
arjunr2 Sep 29, 2025
58a1bc7
Merge remote-tracking branch 'upstream/main'
arjunr2 Oct 8, 2025
ac40e2c
Change target name to `wasm32-linux-muslwali`
arjunr2 Oct 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion clang/lib/Basic/Targets.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -687,7 +687,8 @@ std::unique_ptr<TargetInfo> AllocateTarget(const llvm::Triple &Triple,
}
case llvm::Triple::wasm32:
if (Triple.getSubArch() != llvm::Triple::NoSubArch ||
Triple.getVendor() != llvm::Triple::UnknownVendor ||
(!Triple.isWALI() &&
Triple.getVendor() != llvm::Triple::UnknownVendor) ||
!Triple.isOSBinFormatWasm())
return nullptr;
switch (os) {
Expand All @@ -697,6 +698,10 @@ std::unique_ptr<TargetInfo> AllocateTarget(const llvm::Triple &Triple,
case llvm::Triple::Emscripten:
return std::make_unique<EmscriptenTargetInfo<WebAssembly32TargetInfo>>(
Triple, Opts);
// WALI OS target
case llvm::Triple::Linux:
return std::make_unique<WALITargetInfo<WebAssembly32TargetInfo>>(Triple,
Opts);
case llvm::Triple::UnknownOS:
return std::make_unique<WebAssemblyOSTargetInfo<WebAssembly32TargetInfo>>(
Triple, Opts);
Expand Down
17 changes: 17 additions & 0 deletions clang/lib/Basic/Targets/OSTargets.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -936,6 +936,23 @@ class LLVM_LIBRARY_VISIBILITY WASITargetInfo
using WebAssemblyOSTargetInfo<Target>::WebAssemblyOSTargetInfo;
};

// WALI target
template <typename Target>
class LLVM_LIBRARY_VISIBILITY WALITargetInfo
: public WebAssemblyOSTargetInfo<Target> {
void getOSDefines(const LangOptions &Opts, const llvm::Triple &Triple,
MacroBuilder &Builder) const final {
WebAssemblyOSTargetInfo<Target>::getOSDefines(Opts, Triple, Builder);
// Linux defines; list based off of gcc output
DefineStd(Builder, "unix", Opts);
DefineStd(Builder, "linux", Opts);
Builder.defineMacro("__wali__");
}

public:
using WebAssemblyOSTargetInfo<Target>::WebAssemblyOSTargetInfo;
};

// Emscripten target
template <typename Target>
class LLVM_LIBRARY_VISIBILITY EmscriptenTargetInfo
Expand Down
18 changes: 13 additions & 5 deletions clang/lib/Basic/Targets/WebAssembly.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,12 +88,20 @@ class LLVM_LIBRARY_VISIBILITY WebAssemblyTargetInfo : public TargetInfo {
LongDoubleWidth = LongDoubleAlign = 128;
LongDoubleFormat = &llvm::APFloat::IEEEquad();
MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
// size_t being unsigned long for both wasm32 and wasm64 makes mangled names
// more consistent between the two.
SizeType = UnsignedLong;
PtrDiffType = SignedLong;
IntPtrType = SignedLong;
HasUnalignedAccess = true;
if (T.isWALI()) {
// WALI ABI requires 64-bit longs on both wasm32 and wasm64
LongAlign = LongWidth = 64;
SizeType = UnsignedInt;
PtrDiffType = SignedInt;
IntPtrType = SignedInt;
} else {
// size_t being unsigned long for both wasm32 and wasm64 makes mangled
// names more consistent between the two.
SizeType = UnsignedLong;
PtrDiffType = SignedLong;
IntPtrType = SignedLong;
}
}

StringRef getABI() const override;
Expand Down
2 changes: 2 additions & 0 deletions clang/lib/Driver/Driver.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6833,6 +6833,8 @@ const ToolChain &Driver::getToolChain(const ArgList &Args,
TC = std::make_unique<toolchains::VEToolChain>(*this, Target, Args);
else if (Target.isOHOSFamily())
TC = std::make_unique<toolchains::OHOS>(*this, Target, Args);
else if (Target.isWALI())
TC = std::make_unique<toolchains::WebAssembly>(*this, Target, Args);
else
TC = std::make_unique<toolchains::Linux>(*this, Target, Args);
break;
Expand Down
7 changes: 3 additions & 4 deletions libunwind/src/UnwindRegistersRestore.S
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,8 @@
//
//===----------------------------------------------------------------------===//

#if !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__)

#include "assembly.h"

#define FROM_0_TO_15 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
Expand All @@ -20,8 +22,6 @@
.text
#endif

#if !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__)

#if defined(__i386__)
DEFINE_LIBUNWIND_FUNCTION(__libunwind_Registers_x86_jumpto)
#
Expand Down Expand Up @@ -1250,7 +1250,6 @@ DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind19Registers_loongarch6jumptoEv)

#endif

#endif /* !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__) */

NO_EXEC_STACK_DIRECTIVE

#endif /* !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__) */
8 changes: 4 additions & 4 deletions libunwind/src/UnwindRegistersSave.S
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,8 @@
//
//===----------------------------------------------------------------------===//

#if !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__)

#include "assembly.h"

#define FROM_0_TO_15 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
Expand All @@ -20,8 +22,6 @@
.text
#endif

#if !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__)

#if defined(__i386__)

#
Expand Down Expand Up @@ -1232,6 +1232,6 @@ DEFINE_LIBUNWIND_FUNCTION(__unw_getcontext)
WEAK_ALIAS(__unw_getcontext, unw_getcontext)
#endif

#endif /* !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__) */

NO_EXEC_STACK_DIRECTIVE

#endif /* !defined(__USING_SJLJ_EXCEPTIONS__) && !defined(__wasm__) */
7 changes: 7 additions & 0 deletions llvm/include/llvm/TargetParser/Triple.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -199,6 +199,7 @@ class Triple {
SUSE,
OpenEmbedded,
Intel,
WALI,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is WALI a vendor?

Copy link
Author

@arjunr2 arjunr2 Sep 4, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was discussed during the Rust target addition, and we decided to go with WALi as a vendor for now: https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Support.20for.20a.20new.20.60wasm32-linux-musl.60.20Tie.E2.80.A6.20compiler-team.23797

In reality, long term, we'd just want something like wasm32-linux-musl, but sounds like that would require a standardized Linux interface for Wasm to be accepted.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for consistency it makes sense to have it described as a vendor here as well. It should be a simple to update the target later if necessary.

Copy link
Member

@aheejin aheejin Sep 5, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would WALI be more similar to the environment type, given that we don't actually have a corporate vendor named WALI?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps you're right; were you thinking something like MuslWALI? That'll imply that if variants beyond musl need to be used, we'll need a new enum variant for each.

I'm fine with it either way; I primarily chose this to maintain consistency with Rust. In the future, the goal would be to remove it regardless.

Copy link
Author

@arjunr2 arjunr2 Sep 5, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just referring back to the Zulip thread mentioned, sounds like they would like to see grounds that this is a canonical ABI for Linux/Wasm interactions.

the way I formulated my question was kind of deliberately silly, as I was fishing for "does this reflect a consensus on what the Linux ABI should look like on wasm, formally blessed by such powers that have authority to define Linux?

"because Linus Torvalds says so" is pretty likely to get everyone to fall in line, but in practice something like a cabal of distros would be equally authoritative. even if only because there's few things that actually have cross-distro agreement.

I am unsure what this means concretely since I have yet to bring this up as a canonical ABI for Linux. But this seems to dwell outside the context of LLVM maintainers here, so I'm happy to comply with whatever makes sense from your perspective. If there really is no constraint, I would opt for just dropping wali in vendor/environment altogether

Copy link
Member

@aheejin aheejin Sep 5, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It being a vendor seems weird because the current list of vendors basically only includes companies.

think to minimize cfg changes and have quick support to the ecosystem, target_os would have to be linux and target_env would have to be musl

What is cfg? This sounds like making this as a host environment will make something inconvenient. Is that the case?

If there really is no constraint, I would opt for just dropping wali in vendor/environment altogether

Do all changes in this PR, including the specifications of the type sizes, apply to musl in general?

@dschuff WDYT?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aheejin cfg is how feature gating based on targets is performed at Rust. This is fully independent of the LLVM target backend, so we can make the host environment whatever we want here.

The PR changes are specifically the WALI ABI. Musl is just the only currently supported environment backend

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, triples are well known to be not really sufficient for capturing everything you'd want to know about a compilation, all the aspects of the architecture, set of syscalls available, and ABI; and there's a messy history of vendors with either the same or different ABIs. Since this is adding a new OS and ABI to the set of triples, if an RFC is the right way to go, then we should do that. If the consensus is that we should do something other than just add a vendor, is it too late to modify rustc to agree with LLVM and clang?

Copy link
Author

@arjunr2 arjunr2 Sep 5, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're really not adding a new OS to the set of triples here since we're reusing Linux, just the new ABI for Wasm.

It's not too late to modify the rustc, but notably, that will not really be practical since right now, having the rustc target with arch = wasm32, os = linux, and env = musl allows minimal patching across crates by reusing existing cfg environments. Hence the decision to opt for just the vendor field in Rust -- changing the environment to something else will be a huge pain

Meta,
LastVendorType = Meta
};
Expand Down Expand Up @@ -795,6 +796,12 @@ class Triple {
return getObjectFormat() == Triple::DXContainer;
}

/// Tests whether the target uses WALI Wasm
bool isWALI() const {
return getArch() == Triple::wasm32 && getVendor() == Triple::WALI &&
getOS() == Triple::Linux;
}

/// Tests whether the target is the PS4 platform.
bool isPS4() const {
return getArch() == Triple::x86_64 &&
Expand Down
3 changes: 3 additions & 0 deletions llvm/lib/TargetParser/Triple.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -277,6 +277,8 @@ StringRef Triple::getVendorTypeName(VendorType Kind) {
case PC: return "pc";
case SCEI: return "scei";
case SUSE: return "suse";
case WALI:
return "wali";
case Meta:
return "meta";
}
Expand Down Expand Up @@ -681,6 +683,7 @@ static Triple::VendorType parseVendor(StringRef VendorName) {
.Case("suse", Triple::SUSE)
.Case("oe", Triple::OpenEmbedded)
.Case("intel", Triple::Intel)
.Case("wali", Triple::WALI)
.Case("meta", Triple::Meta)
.Default(Triple::UnknownVendor);
}
Expand Down