AT_FDCWD undefined?

[matthewbauer]

I'm getting this issue building gnulib areadlink.c. The source is available here:

https://github.com/coreutils/gnulib/blob/master/lib/areadlink.c

The error is this:

wasm32-unknown-wasi-clang -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I..  -I../intl -I../intl -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1    -g -O2 -c -o areadlink.o areadlink.c
areadlink.c:41:13: error: use of undeclared identifier 'AT_FDCWD'
  if (fd != AT_FDCWD)
            ^
areadlink.c:55:24: error: use of undeclared identifier 'AT_FDCWD'
  return careadlinkat (AT_FDCWD, filename, NULL, 0, NULL, careadlinkatcwd);
                       ^
2 errors generated.
make[6]: *** [Makefile:1496: areadlink.o] Error 1

AT_FDCWD should be available in wasi, correct? I can't find any direct references outside of Musl though. If it's not provided, what alternatives are available?

You can repro this with nix:

$ nix build -f channel:nixpkgs-unstable pkgsCross.wasi32.gettext --arg config '{ allowUnsupportedSystem = true; }'

/cc @Ericson2314

[Ericson2314]

So WASI has no working directory. https://github.com/musec/libpreopen emulates it instead. https://github.com/musec/libpreopen probably need to wrap even *at functions so that AT_FDCWD can work.

[sunfishcode]

That's right. The WASI API layer has no concept of AT_FDCWD, which would imply an ambient authority to access the current directory, but it would be possible to emulate with more libpreopen-like wrappers.

[Ericson2314]

Issue already exists musec/libpreopen#11 .

[Ericson2314]

Ah I see the libraries are vendored in. @sunfishcode if git submodule is too much of a pain, would you be open to git subtree? Insofar that there is an upstream issue it would be nice to land the feature both places.

[sunfishcode]

We do have numerous local changes to libpreopen, so it's not trivial to do. At a high level, libpreopen is architected to work in a Capsicum-like environment where it's a library on top of libc. However in WASI libc, we're using it as part of the libc, which changes how some things work.

If anyone wants to implement this in upstream libpreopen, I'm happy to update WASI's vendored copy. That said, this feature seems like it will be a little tricky to do as a library on top of libc. It would want to intercept openat so that it can handle AT_FDCWD, but it still needs to be able to call the underlying openat in libc. This is something we could more easily do with libpreopen being part of libc.

For example, we could do this:

• Rename the existing openat to __wasilibc_nocwd_openat (or something) in libc-bottom-half/cloudlibc/src/libc/fcntl/openat.c
• Define a new openat which just does this:
  • if the dirfd is AT_FDCWD, call open
  • otherwise call __wasilibc_nocwd_openat

[Ericson2314]

Yeah fair point about this interposition being such a pain with C having no namespacing.

[Ericson2314]

I almost want to go rewrite with https://gitlab.redox-os.org/redox-os/relibc, haha.

[emaste]

It's straightforward (if a bit ugly) to intercept *at and conditionally pass through to the real function, using dlsym and RTLD_NEXT. I might have a look at implementing this during a FreeBSD hackathon in two weeks.

[sunfishcode]

That's a clever idea. WASI libc doesn't support dynamic linking yet though, so for our purposes here, we'll still need some other approach.

[Ericson2314]

@emaste it would also be interesting to use CPP / configure script to prefix the function names. that would work for static linking too to some extent.

[sunfishcode]

I started sketching out a minimal version of my idea above, but many of the changes are relatively mechanical and I ended up with a complete, though still rough, draft: #54.