[clang] Add -stdlib=libstdc++ support for webassembly

[expnkx]

Summary

I have successfully built libstdc++ with clang on wasm32-wasi, but the clang front-end always assumes we are using -stdlib=libc++.

This patch is to add support for -stdlib=libstdc++ for webassembly.
https://gcc.gnu.org/pipermail/libstdc++/2021-April/052429.html

I do not know whether add -stdlib=libstdc++ in the test will break the code. Let's just try it.

[expnkx]

It is impossible to do any real test because libstdc++ is a part of GCC and GCC does not provide wasm32 and wasm64 backend.

See
https://gcc.gnu.org/pipermail/libstdc++/2021-April/052429.html

[sbc100]

I think should should be able to add some tests to clang/test/Driver/wasm-toolchain.c

clang/lib/Driver/ToolChains/WebAssembly.cpp

443

Although it makes no odds with wasm-ld should. logically,stdc++ come before supc++? Like c++ comes before c++abi above? (This seems to be the case in clang/lib/Driver/ToolChains/BareMetal.cpp

[sbc100]

clang/lib/Driver/ToolChains/WebAssembly.cpp

388–420

This seems to add an early exit for OPT_nostdinc where none existed before. Different targets seems to disagree about whether to do this. To keep this change a focused as possible maybe revert that part of the change?

[expnkx]

wait me for fixing them

[expnkx]

In D101464#2723028, @sbc100 wrote:

I think should should be able to add some tests to clang/test/Driver/wasm-toolchain.c

How to test it? I guess no one in the world besides me knows how to build libstdc++ for wasm.

[sbc100]

In D101464#2723039, @expnkx wrote:

In D101464#2723028, @sbc100 wrote:

I think should should be able to add some tests to clang/test/Driver/wasm-toolchain.c

How to test it? I guess no one in the world besides me knows how to build libstdc++ for wasm.

That tests in clang/test/Driver/wasm-toolchain.c don't actually require any kind of libc (or indeed any libraries) to exist. They just test the behaviour of the driver itself in terms of what sub-commands in runs.

[jwakely]

clang/lib/Driver/ToolChains/WebAssembly.cpp

443

Every symbol in libsupc++.a is also in libstdc++.so and libstdc++.a so -lstdc++ -lsupc++ should be exactly equivalent to -lstdc++.

I suppose ordering them this way means the linker might be able to use libsupc++.a to resolve everything, and so not need to link to libstdc++.so at all (e.g. if there is a wasm equivalent of --as-needed). But I don't know if that's even relevant for wasm.

[expnkx]

i have removed -lsupc++, just -lstdc++

[expnkx]

I just realized the version is incorrect. GCC master is currently at 12.0.0. GCC 13.0.0 will be a thing one year later. It is pointless to add the test here.

Remove it.

https://github.com/expnkx/GCC-12-libstdc-for-wasm32-wasi

Here is my build of sysroot for wasm32-wasi. You can try this if you want.

[expnkx]

clang/lib/Driver/ToolChains/WebAssembly.cpp

388–420

fixed

443

fixed

[expnkx]

I just realized clang-tidy said there is a change which requires. Fix it.

[expnkx]

Approved!

[expnkx]

clang-tidy complains again. Fix it

[expnkx]

it is weird, why is this test -stdlib=c++ instead of -stdlib=libc++?? Is that legal?

[expnkx]

what's happening with the build?

[expnkx]

let me try this patch. It removes unknown OS checks.

[expnkx]

I finally realize what is happening here. The virtual filesystem emits // instead of \ for seperator.

Also adds a basic link and compile test for -stdlib=libstdc++

[expnkx]

Looks like it is a naming collision?

[expnkx]

Force the front end emitting the Unix style path to get rid of troubles in the testcase.

[expnkx]

remove libstdc++ test first. Let me see what's actually going wrong here.

[expnkx]

I guess the multiarch include order matters for tests.

[expnkx]

DONE :)

Time to merge it :)

[echristo]

I think Sam or Jonathan would be good reviewers here.

-eric

[sbc100]

This comment has been deleted.

clang/lib/Driver/ToolChains/WebAssembly.cpp

390

I've not seen this style in widespread use in llvm yet .. I guess its somehow preferred over std::string SysRoot(X) or std::string SysRoot = X; ? Unless this is documented as preferred somewhere I would stick more conventional form (or maybe I'm just out-of-date here).

417

I'm curious if this code is based on something existing in another driver or if its something you created from scratch? Could this kind of logic could be shared? I see other drivers using something called GCCInstallation but maybe that doesn't make sense for some reason here (i..e maybe its not suitable for cross compilers like us?)

420

Perhaps break; here is more future proof (in case code gets added after the switch)

clang/test/Driver/wasm-toolchain.cpp

17 ↗

(On Diff #341410)

This is an interesting/breaking change.. it seems that we splelt this wrong in the WebAssembly driver from the beginning. The docs clearly say this flag should be --stdlib=libc++ : https://libcxx.llvm.org/docs/UsingLibcxx.html#getting-started

I'm fairly certain we don't have anyone using this in the wild (since there is only one possible option here), but I think it might be worth splitting this out into its owr PR that just fixes this naming mistake. It seems logical to separate it from adding support for libstdc++ and will make the possible revert of one or change or the other easier if it ever comes to that.

69 ↗

(On Diff #341410)

I suppose we don't see the include paths here because the driver doesn't see them on the filesystem? It looks like the linux driver uses a dummy sysroot tree to enable testing of these:

lang/test/Driver/linux-header-search.cpp:

// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \                  
// RUN:     -target x86_64-unknown-linux-gnu \                                      
// RUN:     -stdlib=libc++ \                                                        
// RUN:     -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \                   
// RUN:     -resource-dir=%S/Inputs/resource_dir \                                  
// RUN:     --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \                         
// RUN:     --gcc-toolchain="" \                                                    
// RUN:   | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-SYSROOT %s                
// CHECK-BASIC-LIBCXXV2-SYSROOT: "{{[^"]*}}clang{{[^"]*}}" "-cc1"                   
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"                    
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/include/x86_64-unknown-linux-gnu/c++/v2"
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v2"                                     
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/local/include"

[expnkx]

Let me fix the 2 formatting issues first.

[expnkx]

The Webassembly.cpp has updated since last time I upload this patch. Reupload again

[expnkx]

build fail

[expnkx]

use clang format to clean up webassembly.cpp

[expnkx]

clang-tidy is a sad story

[expnkx]

clang format + clang tidy.

I think the fclang front end crashes.

[expnkx]

update for today's patch

clang/lib/Driver/ToolChains/WebAssembly.cpp

 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/Support/VirtualFileSystem.h"
 
 using namespace clang::driver;
 using namespace clang::driver::tools;

 WebAssembly::GetCXXStdlibType(const ArgList &Args) const {
   if (Arg *A = Args.getLastArg(options::OPT_stdlib_EQ)) {
     StringRef Value = A->getValue();
-    if (Value != "libc++")
+    if (Value == "libc++")
+        return ToolChain::CST_Libcxx;
+    else if(Value == "libstdc++")
+        return ToolChain::CST_Libstdcxx;
+    else
       getDriver().Diag(diag::err_drv_invalid_stdlib_name)
           << A->getAsString(Args);
   }

 
 void WebAssembly::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
                                                ArgStringList &CC1Args) const {
-  if (!DriverArgs.hasArg(options::OPT_nostdlibinc) &&
-      !DriverArgs.hasArg(options::OPT_nostdincxx)) {
-    if (getTriple().getOS() != llvm::Triple::UnknownOS) {
-      const std::string MultiarchTriple =
-          getMultiarchTriple(getDriver(), getTriple(), getDriver().SysRoot);
-      addSystemInclude(DriverArgs, CC1Args,
-                       getDriver().SysRoot + "/include/" + MultiarchTriple +
-                           "/c++/v1");
+  if (DriverArgs.hasArg(options::OPT_nostdinc) ||
+      DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+      DriverArgs.hasArg(options::OPT_nostdincxx))
+    return;
+  SmallString<128> Dir{getDriver().SysRoot};
+  const std::string MultiarchTriple =
+      getMultiarchTriple(getDriver(), getTriple(), getDriver().SysRoot);
+  llvm::sys::path::append(Dir, "include");
+  switch (GetCXXStdlibType(DriverArgs)) {
+  case ToolChain::CST_Libcxx: {
+    SmallString<128> native{Dir};
+    llvm::sys::path::append(native, "c++", "v1");
+    addSystemInclude(DriverArgs, CC1Args, native);
+    llvm::sys::path::append(Dir, MultiarchTriple, "c++", "v1");
+    addSystemInclude(DriverArgs, CC1Args, Dir);
+    break;
+  }
+  case ToolChain::CST_Libstdcxx: {
+    llvm::sys::path::append(Dir, "c++");
+    std::error_code EC;
+    Generic_GCC::GCCVersion Version = {"", -1, -1, -1, "", "", ""};
+    // Walk the subdirs, and find the one with the newest gcc version:
+    for (llvm::vfs::directory_iterator
+             LI = getVFS().dir_begin(Dir.str(), EC),
+             LE;
+         !EC && LI != LE; LI = LI.increment(EC)) {
+      StringRef VersionText = llvm::sys::path::filename(LI->path());
+      auto CandidateVersion = Generic_GCC::GCCVersion::Parse(VersionText);
+      if (CandidateVersion.Major == -1)
+        continue;
+      if (CandidateVersion <= Version)
+        continue;
+      Version = CandidateVersion;
     }
-    addSystemInclude(DriverArgs, CC1Args,
-                     getDriver().SysRoot + "/include/c++/v1");
+    if (Version.Major == -1)
+      return;
+    llvm::sys::path::append(Dir, Version.Text);
+    addSystemInclude(DriverArgs, CC1Args, Dir);
+    llvm::sys::path::append(Dir, MultiarchTriple);
+    addSystemInclude(DriverArgs, CC1Args, Dir);
+    break;
+  }
   }
 }
 

     CmdArgs.push_back("-lc++abi");
     break;
   case ToolChain::CST_Libstdcxx:
+    CmdArgs.push_back("-lsupc++");
+    CmdArgs.push_back("-lstdc++");
+    break;
+  default:
     llvm_unreachable("invalid stdlib name");
   }
 }