Cause llvm-libc are in early stage, and we can easily catch up the support with linux.
After we add wasi support in llvm-lic, we can easily get a usable llvm-libc across different platform such as linux/windows/macos/android. don’t know if iOS is a target, but these target are very much enough
Cause llvm-libc are in early stage, and we can easily catch up the support with linux.
After we add wasi support in llvm-lic, we can easily get a usable llvm-libc across different platform such as linux/windows/macos/android. don’t know if iOS is a target, but these target are very much enough
I do not see any technical blockers for the platform independent parts. Of course, work has to be done to set up the build etc.
What exactly do you mean by, “we can easily get a usable llvm-libc across different platforms such as linux/windows/macos/android.”
Somehow I wish not all parts of a libc but parts that can be provided without a JavaScript wrapper for .wasm can be provided from llvm’s libc (leaving a stab implementation for the rest like file system). I’ve put together a minimal libc on 1 so using a 26kb .wasm binary file one can decode both PNG and JPG using this 2 simple to integrate JavaScript code, can be easily ported in other contexts .wasm can be interpreted without worrying about a helper. I had to use -nostdlib and -nostdinc in my build script but I wished the llvm-libc initiative can make it simpler so I don’t have to put together a minimal libc for my need.
Something similar can be achieved in Rust world using --target wasm32-unknown-unknown e.g. 3 which I guess can be best lead here also in terms what can be in scope of this work.
Somehow I wish not all parts of a libc but parts that can be provided without a JavaScript wrapper for .wasm can be provided from llvm’s libc (leaving a stab implementation for the rest like file system). I’ve put together a minimal libc on [1] so using a 26kb .wasm binary file one can decode both PNG and JPG using this [2] simple to integrate JavaScript code, can be easily ported in other contexts .wasm can be interpreted without worrying about a helper. I had to use -nostdlib and -nostdinc in my build script but I wished the llvm-libc initiative can make it simpler so I don’t have to put together a minimal libc for my need.
The tricky part would be header files. When you pick only a part of LLVM libc, where will you get the libc headers from? You can choose to use headers from the other libc and stick to platform independent and ABI insensitive parts from LLVM libc.
[*] Since Linux is the only platform we test on currently, there might be some holes/bugs in LLVM libc’s infrastructure that might need to be plugged/fixed before bringing up LLVM libc for wasm.
WASI indeed is still evolving, and WASI libc is actively evolving along with it. I expect that it won’t make sense to upstream libc pieces until we have more of the big-picture design finished.
I wonder if you can help me to test this, I have a llvm build setup so having some quick instructions on how to test this even on x86_64 would be nice so maybe I can adopt it with my wasm work.
Okay I am making my way through this somehow, hopefully I can reach to somewhere and document the steps so feel free to ignore my last email here. Thanks
Okay I am making my way through this somehow, hopefully I can reach to somewhere and document the steps so feel free to ignore my last email here. Thanks
Hi,
If you still need to ask questions, feel free to do so. Also, if you find something can be done better, feel free to suggest.