[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses it

[sunfish]

Summary

This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. It also introduce a wasm OS name that uses this support.

[Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/

[sunfish]

From a survey and some testing, Emscripten doesn't appear to rely on these paths, so this just affects things like wasmception and the waterfall, which should be straightforward to update.

[dschuff]

LGTM but is there really no test for this? I'd expect to see this on linker command lines or something, right? If not we should add one.

[sbc100]

My understanding is that names like "lib32" and "lib64", at least for x86/amd64 are the old fashioned (legact) way of doing multi-arch. I things a better approach it to either provide and single-arch sysroot (where /usr/lib contains what you want) or a multi-arch setup (where you would use something like /usr/lib/x86_64-linux-gnu/). Since other parts of a sysroot need to be arch specific I suggest we stick with the former option and assume a separate sysroot for each architecture and sub-architecture.

So, while I don't support this change, I would support something like adding "/lib/wasm32-unknown-unknown" before "/lib" in the default library path.

[sunfish]

Per @sbc100's comment, this update switches to full multilib paths.

[sbc100]

Ooo - a new OS is born!

Perhaps create a separate change to introduce the new OS? .. which will then make this CL tiny and specific to what the CL title says it is doing.

tools/clang/lib/Driver/ToolChains/WebAssembly.cpp

95 ↗

(On Diff #181584)

For include paths you have multiarch + default but for library paths you have multiarch *or* default. Is that deliberate?

[dschuff]

One difference between the multilib style and multi-arch style is whether any headers can be shared between the 2 arches. Historically at least, with bitness-flavored variants of the same architecture there were common headers used by both, and it was just the library directories that needed to be different. I've heard anecdotally that this is not the case for ARM though.

Would we expect that users might want to use a single sysroot to generate code for both 32-and 64-bit output?

[sunfish]

In D56553#1356467, @sbc100 wrote:

Ooo - a new OS is born!

Perhaps create a separate change to introduce the new OS? .. which will then make this CL tiny and specific to what the CL title says it is doing.

Without the new OS I wouldn't be able to fully test the new functionality, as we have no other wasm OS's in tree. Is the size of this patch an issue?

tools/clang/lib/Driver/ToolChains/WebAssembly.cpp

95 ↗

(On Diff #181584)

Yes; I followed https://wiki.debian.org/Multiarch/Implementation . "include" can contain platform-independent headers, while libraries are inherently platform-dependent.

[sunfish]

In D56553#1356482, @dschuff wrote:

One difference between the multilib style and multi-arch style is whether any headers can be shared between the 2 arches. Historically at least, with bitness-flavored variants of the same architecture there were common headers used by both, and it was just the library directories that needed to be different. I've heard anecdotally that this is not the case for ARM though.

Would we expect that users might want to use a single sysroot to generate code for both 32-and 64-bit output?

Perhaps when we add support for wasm64, we could also add an additional include path "include/wasm-$OS", separate from "include/wasm32-$OS" and "include/wasm64-$OS", which could be shared by both wasm32 and wasm64, but still specific to wasm.

[sunfish]

Or, here's another idea: What if we *just* add "include/wasm-$OS" and don't add "wasm32-$OS" or "wasm64-$OS"-specific include directories? Most headers for wasm will probably be shared between the two, and for anything that really can't be, we always have the __wasm32__ and __wasm64__ predefined macros.

[sbc100]

In D56553#1356654, @sunfish wrote:

In D56553#1356467, @sbc100 wrote:

Ooo - a new OS is born!

Perhaps create a separate change to introduce the new OS? .. which will then make this CL tiny and specific to what the CL title says it is doing.

Without the new OS I wouldn't be able to fully test the new functionality, as we have no other wasm OS's in tree. Is the size of this patch an issue?

Not so much the size of the patch, but more that atomicity. Introducing the new OS seems like an naturally separate change to me.

If you don't want to split it at least update the CL title and description.

[sbc100]

Looking that the behaviour for x86 clang it looks like -L/lib -L/usr/lib are always appended for both -m32 and -m64 with the arch specific directories coming first.

[sbc100]

Can you make change to llvm and clang at the same time? I thought that was not possible..

[sunfish]

Title updated.

In D56553#1356705, @sbc100 wrote:

Looking that the behaviour for x86 clang it looks like -L/lib -L/usr/lib are always appended for both -m32 and -m64 with the arch specific directories coming first.

My reading of https://wiki.debian.org/Multiarch/Implementation is that /lib and /usr/lib don't exist a full multi-arch world. I assume they're still around on x86 because the transition to multiarch is still ongoing and some packages still expect to install their libs there. I'd prefer to avoid adding it since it could cause trouble if anyone actually created a multilib sysroot with non-wasm libs in /lib.

[sunfish]

In D56553#1356720, @sbc100 wrote:

Can you make change to llvm and clang at the same time? I thought that was not possible..

That's right, I'll commit the two parts separately.

[dschuff]

include/llvm/ADT/Triple.h

191 ↗

(On Diff #181584)

The fact that COWS comes right after Hurd makes me way happier than it should.

llvm/trunk/include/llvm/ADT/Triple.h

enum OSType {
     ELFIAMCU,
     TvOS,       // Apple tvOS
     WatchOS,    // Apple watchOS
     Mesa3D,
     Contiki,
     AMDPAL,     // AMD PAL Runtime
     HermitCore, // HermitCore Unikernel/Multikernel
     Hurd,       // GNU/Hurd
-    LastOSType = Hurd
+    COWS,       // Capability-Oriented WebAssembly Syscalls
+    LastOSType = COWS
   };
   enum EnvironmentType {
     UnknownEnvironment,
 
     GNU,
     GNUABIN32,
     GNUABI64,
     GNUEABI,
bool isOSKFreeBSD() const {
     return getOS() == Triple::KFreeBSD;
   }
 
   /// Tests whether the OS is Hurd.
   bool isOSHurd() const {
     return getOS() == Triple::Hurd;
   }
 
+  /// Tests whether the OS is COWS.
+  bool isOSCOWS() const {
+    return getOS() == Triple::COWS;
+  }
+
   /// Tests whether the OS uses glibc.
   bool isOSGlibc() const {
     return (getOS() == Triple::Linux || getOS() == Triple::KFreeBSD ||
             getOS() == Triple::Hurd) &&
            !isAndroid();
   }
 
   /// Tests whether the OS uses the ELF binary format.

llvm/trunk/lib/Support/Triple.cpp

StringRef Triple::getOSTypeName(OSType Kind) {
   case ELFIAMCU: return "elfiamcu";
   case TvOS: return "tvos";
   case WatchOS: return "watchos";
   case Mesa3D: return "mesa3d";
   case Contiki: return "contiki";
   case AMDPAL: return "amdpal";
   case HermitCore: return "hermit";
   case Hurd: return "hurd";
+  case COWS: return "cows";
   }
 
   llvm_unreachable("Invalid OSType");
 }
 
 StringRef Triple::getEnvironmentTypeName(EnvironmentType Kind) {
   switch (Kind) {
   case UnknownEnvironment: return "unknown";
return StringSwitch<Triple::OSType>(OSName)
     .StartsWith("elfiamcu", Triple::ELFIAMCU)
     .StartsWith("tvos", Triple::TvOS)
     .StartsWith("watchos", Triple::WatchOS)
     .StartsWith("mesa3d", Triple::Mesa3D)
     .StartsWith("contiki", Triple::Contiki)
     .StartsWith("amdpal", Triple::AMDPAL)
     .StartsWith("hermit", Triple::HermitCore)
     .StartsWith("hurd", Triple::Hurd)
+    .StartsWith("cows", Triple::COWS)
     .Default(Triple::UnknownOS);
 }
 
 static Triple::EnvironmentType parseEnvironment(StringRef EnvironmentName) {
   return StringSwitch<Triple::EnvironmentType>(EnvironmentName)
     .StartsWith("eabihf", Triple::EABIHF)
     .StartsWith("eabi", Triple::EABI)
     .StartsWith("gnuabin32", Triple::GNUABIN32)

llvm/trunk/unittests/ADT/TripleTest.cpp

TEST(TripleTest, ParsedIDs) {
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
 
   T = Triple("wasm32-unknown-unknown");
   EXPECT_EQ(Triple::wasm32, T.getArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
 
+  T = Triple("wasm32-unknown-cows-musl");
+  EXPECT_EQ(Triple::wasm32, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::COWS, T.getOS());
+  EXPECT_EQ(Triple::Musl, T.getEnvironment());
+
   T = Triple("wasm64-unknown-unknown");
   EXPECT_EQ(Triple::wasm64, T.getArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
 
+  T = Triple("wasm64-unknown-cows-musl");
+  EXPECT_EQ(Triple::wasm64, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::COWS, T.getOS());
+  EXPECT_EQ(Triple::Musl, T.getEnvironment());
+
   T = Triple("avr-unknown-unknown");
   EXPECT_EQ(Triple::avr, T.getArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
 
   T = Triple("avr");
   EXPECT_EQ(Triple::avr, T.getArch());
TEST(TripleTest, FileFormat) {
 
   EXPECT_EQ(Triple::COFF, Triple("i686--win32").getObjectFormat());
 
   EXPECT_EQ(Triple::ELF, Triple("i686-pc-windows-msvc-elf").getObjectFormat());
   EXPECT_EQ(Triple::ELF, Triple("i686-pc-cygwin-elf").getObjectFormat());
 
   EXPECT_EQ(Triple::Wasm, Triple("wasm32-unknown-unknown").getObjectFormat());
   EXPECT_EQ(Triple::Wasm, Triple("wasm64-unknown-unknown").getObjectFormat());
+  EXPECT_EQ(Triple::Wasm, Triple("wasm32-unknown-cows-musl").getObjectFormat());
+  EXPECT_EQ(Triple::Wasm, Triple("wasm64-unknown-cows-musl").getObjectFormat());
 
   EXPECT_EQ(Triple::Wasm,
             Triple("wasm32-unknown-unknown-wasm").getObjectFormat());
   EXPECT_EQ(Triple::Wasm,
             Triple("wasm64-unknown-unknown-wasm").getObjectFormat());
+  EXPECT_EQ(Triple::Wasm,
+            Triple("wasm32-unknown-cows-musl-wasm").getObjectFormat());
+  EXPECT_EQ(Triple::Wasm,
+            Triple("wasm64-unknown-cows-musl-wasm").getObjectFormat());
 
   Triple MSVCNormalized(Triple::normalize("i686-pc-windows-msvc-elf"));
   EXPECT_EQ(Triple::ELF, MSVCNormalized.getObjectFormat());
 
   Triple GNUWindowsNormalized(Triple::normalize("i686-pc-windows-gnu-elf"));
   EXPECT_EQ(Triple::ELF, GNUWindowsNormalized.getObjectFormat());
 
   Triple CygnusNormalised(Triple::normalize("i686-pc-windows-cygnus-elf"));