Latest wasi-libc
#109
Latest wasi-libc
#109
Conversation
…e wasi with emulation
…ired by wasi-libc's calloc implementation
Shillaker
left a comment
There was a problem hiding this comment.
Tiny comment on LLVM version, otherwise LGTM 👍
| @@ -1,4 +1,5 @@ | |||
| FROM faasm/llvm:13.0.1 as llvm | |||
| # llvm image is not re-built often, so the tag may be behind | |||
| FROM faasm/llvm:0.2.2 as llvm | |||
There was a problem hiding this comment.
This image was tagged with the LLVM image used to build it (i.e. used to be LLVM 13.0.1). It makes it clearer which LLVM version is being used IMO
There was a problem hiding this comment.
When updating the PR description, I removed the explanation of this change.
Turns out that installing LLVM (inc. libc) populates the sysroot with files (e.g. header files) that are not necessarily removed when re-building libc from scratch. Thus, different libc configurations for the same llvm version would yield different container images.
Even though adding the --purge flag to llvm.libc should do the trick, I am not enitrely sure. Thus, rather than having docker image inconsitencies I change the tagging mechanism.
In this PR I rebase our
wasi-libcfork to the latest upstream. Most importantly, many things that were not supported when we first forkedwasi-libchave now been implemented (i.e. emulated). For example, signals or process clocks. So I use those when possible.The diff between faasm's branch and the latest upstream head can be inspected here. I would like to simplify it further (e.g. removing syscalls support in Faasm?), but this is out of the scope of this PR.
The summary of changes after the rebase are the following:
wasi-libc. Not doing so, prevented catching some bugs of dependencies building with older sysroots.mmap/munmapis also supported as part ofwasi-libcnow. I ammend our demo functions to compile with both ourmmapimplementation andwasi-libc's.