Bug#1020746: wasm32-unknown-wasi target attempts to use non-existing include paths

[Faidon Liambotis]

Package: clang-14
Version: 1:14.0.6-2
Severity: normal

Attempting to build a trivial "hello world" program for
the wasm32-unknown-wasi target with:
  clang -v -target wasm32-linux-wasi -o test.wasm test.c

...results in a cc1 command-line that includes:
   -internal-isystem /include/wasm32-wasi -internal-isystem /include
...naturally followed by:
  ignoring nonexistent directory "/include/wasm32-wasi"
  ignoring nonexistent directory "/include"

If one were to pass "-I/usr/include/wasm32-wasi" to work around this, it
becomes apparent that a similar situation is the case for -L:
  wasm-ld-14 ... -L/lib/wasm32-wasi /lib/wasm32-wasi/crt1-command.o ...

Looking at the source, sysroot is prepended on these paths, and seems to
be implied to be always expected. Presumably this originated in a world
where folks had the WASI SDK (and wasi-libc) installed in /opt.

In Debian, the wasi-libc package (the libc for this platform) uses the
/usr/include/wasm32-wasi and /usr/lib/wasm32-wasi paths. Apparently
passing --with-sysroot=/usr works around this issue, pointing clang to
the right paths in Debian.

However, it would be ideal if that indirection was not necessary, and
clang did the right thing out of the box, instead of attempting to
access nonexisting unprefixed paths like /include/.

An example, *untested* kinda hacky fix for this could take the form of
adding this to clang/lib/Driver/ToolChains/WebAssembly.cpp:

  std::string WASI::computeSysRoot() const {
    if (!getDriver().SysRoot.empty())
      return getDriver().SysRoot;
  
    std::string Path = "/usr";
    if (getVFS().exists(Path))
      return Path;
  
    return std::string();
  }

Also see #1014567 which describes my confusion upon encountering
wasi-libc. It can be resolved if this bug is accepted, or repurposed to
be a documentation wishlist bug.

Finally, note that even with the fix described in this bug, compilations
to the wasm32-linux-wasi target will not work until #1010932
(availability of compiler-rt for wasm32) is resolved.

Regards,
Faidon