Update to the next version of the witx crate
#234
Conversation
|
Note that this is dependant on WebAssembly/WASI#395, so this should probably wait for that to get settled first. |
* Generate adapter functions instead of simply a header file to have a place where adapter code can go. * Implement adapters in terms of the instructions that the `witx` crate tells us about. * Update the interface of functions to what `witx` expects, notably string arguments are now only taken as `char*` and `strlen` happens in the adapter function. * Update defined/predefined/undefined symbol lists for types that have been updated. Some precise generated code has changed but the actual APIs should all be the same except for the change to not take the length of the string in the raw WASI call, since idiomatically C doesn't pass the length of strings around. Eventually it's expected that the shim functions, while sometimes not necessary today, will implement more checks and more conversions as necessary for new APIs.
alexcrichton
force-pushed
the
witx-next
branch
from
f0680dc to
8bbb07f
Compare
| @@ -10,8 +10,7 @@ | |||
| #include <unistd.h> | |||
|
|
|||
| int __wasilibc_nocwd_symlinkat(const char *path1, int fd, const char *path2) { | |||
| __wasi_errno_t error = | |||
| __wasi_path_symlink(path1, strlen(path1), fd, path2, strlen(path2)); | |||
| __wasi_errno_t error = __wasi_path_symlink(path1, fd, path2); | |||
There was a problem hiding this comment.
Given that these are now library calls its makes me wonder if we should continue to use the __ prefix. Perhaps these should be just wasi_path_symlink and then the real imports could be __wasi_path_symlink? Would most likely mean changing all the types too.
There was a problem hiding this comment.
I'm happy to implement either way, but @sunfishcode would probably be best to answer the question (I'm not familiar enough with C idioms to know what best to do here).
There was a problem hiding this comment.
The __ prefix continues to make sense :-). For example, users can call WASI APIs directly, and may have their own wasi_* wrappers around things, so the __ prefix here ensures that even if they do that, they can also link in libc at the same time.
There was a problem hiding this comment.
That said, if we wanted to make it easier for people to write code that calls directly into WASI, one thing we could do would be to provide weak aliases named wasi_* that point to the __wasi_ symbols.
There was a problem hiding this comment.
I just think maybe the __ prefix is not the right way to carve of our own namespace. Of course this is unrelated to this PR, but I think __ is normally reserved for toolchain internal stuff isn't it?
Again, unrelated to this PR.
There was a problem hiding this comment.
The C standard just says "reserved for any use". In practice, musl, glibc, and other libc impls commonly use __ for their own purposes.
| )); | ||
|
|
||
| __wasi_size_t *retptr0, | ||
| __wasi_size_t *retptr1 |
There was a problem hiding this comment.
Looks like we lost some information here about what these pointers mean.
There was a problem hiding this comment.
Yeah unfortunately the documentation got shuffled a bit since each individual parameter is no longer documented in the source file, although I tried to make sure that the documentation was at least preserved somewhat in the @return section for the function
There was a problem hiding this comment.
Any why we can keep the argc and argv_buf_size names some how?
Can these be retptr_argc and retptr_argv_buf_size perhaps? retptr0 and retptr1 are not very useful names.
There was a problem hiding this comment.
Unfortuantely this is mostly due to a change in the *.witx file itself -- WebAssembly/WASI@ef8c1a5#diff-2f2ab5a9d79cd5c57a981bf769e772aa60405857803bcdbde3c3e8179315abb8L24-R26
Where previously there were separate result variables it's now modeled more closely with the intended interface type, which is a Result<(usize, usize), Errno>. This means that there's no way really to auto-generate the names as before since from the source it's just "return pointer for first tuple element" and the second one.
There was a problem hiding this comment.
There's a trade-off here where we could get names for these values back by returning a record rather than a tuple, but that would break the ABI today (records always turn into a C struct, which gets passed by one pointer rather than multiple). Its a little but unfortunate but I think losing those names is OK for now.
Make it a bit clearer that they're the ones that we're importing and calling.
place where adapter code can go.
witxcratetells us about.
witxexpects, notablystring arguments are now only taken as
char*andstrlenhappens inthe adapter function.
been updated.
Some precise generated code has changed but the actual APIs should all
be the same except for the change to not take the length of the string
in the raw WASI call, since idiomatically C doesn't pass the length of
strings around.
Eventually it's expected that the shim functions, while sometimes not
necessary today, will implement more checks and more conversions as
necessary for new APIs.