[llvm-dev] [libc-dev] How about add webassembly/wasi support in llvm-libc.

[Ebrahim Byagowi via llvm-dev]

Hi Siva,

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.

Thanks!

On Wed, Sep 23, 2020 at 11:33 PM Siva Chandra <sivachandra at google.com>
wrote:

> On Wed, Sep 23, 2020 at 12:47 PM Ebrahim Byagowi <ebraminio at gmail.com>
> wrote:
>
>> 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.
>>
>
> Such a use case is supported by LLVM libc [*]. One will have set up a few
> config files for wasm. See
> https://github.com/llvm/llvm-project/blob/master/libc/config/linux/api.td
> and
> https://github.com/llvm/llvm-project/blob/master/libc/config/linux/x86_64/entrypoints.txt
> .
>
> 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.
>
> 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.
>>
>>  [1]: https://github.com/harfbuzz/harfbuzzjs/tree/edf1d8b/libc
>>  [2]:
>> https://github.com/harfbuzz/harfbuzzjs/blob/gh-pages/stb-image/index.html
>>  [3]: https://github.com/RazrFalcon/ttf-parser/commit/b0cfc67
>>
>> On Wed, Sep 23, 2020 at 9:16 PM Siva Chandra via libc-dev <
>> libc-dev at lists.llvm.org> wrote:
>>
>>> +cc libc-dev
>>>
>>> On Wed, Sep 23, 2020 at 9:44 AM 罗勇刚(Yonggang Luo) via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> 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."
>>>
>>>
>>>> --
>>>>          此致
>>>> 礼
>>>> 罗勇刚
>>>> Yours
>>>>     sincerely,
>>>> Yonggang Luo
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>>> libc-dev mailing list
>>> libc-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libc-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210130/2510cd66/attachment.html>