Dev/wasi libc windows #2740
Merged
Dev/wasi libc windows #2740
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Build wasi-libc library on Windows since libuv may be not supported. This PR is a first step to make it working, but there's still a number of changes to get it fully working.
…ry (#2377) There is no standard `realpath` function in the C/C++ standard libraries for Windows, use `_fullpath` function instead to get absolute path of a directory.
* disable translations of errno codes that aren't defined on Windows * undef `min()` macro if it is defined to not conflict with the `min()` function we define * implement `shed_yield` wasi call * disable some of the features in the config for windows by default
And return ENOSYS. We do that so we can at least compile the code on CI. We'll be gradually enabling more and more functions. Also, enabled `proc_raise()` for windows.
Merge branch main into dev/wasi-libc-windows
Update wamr-test-suites scripts to enable running spec tests on Windows. We don't enable those tests in CI yet as not all of them are passing.
Tests are not passing yet therefore we don't enable them in CI.
MASM (Microsoft Macro Assembler) needs to be enabled to successfully compile .asm files on Windows. Without enabling this language automatically in runtime_lib.cmake, Windows cmake projects using WAMR get hard-to-diagnose linker errors about missing symbols as the assembly file is not compiled at all.
To allow non-POSIX platforms such as Windows to support WASI libc filesystem functionality, create a set of wrapper functions which provide a platform-agnostic interface to interact with the host filesystem. For now, the Windows implementation is stubbed but this will be implemented properly in a future PR. There are no functional changes in this change, just a reorganization of code to move any direct POSIX references out of posix.c in the libc implementation into posix_file.c under the shared POSIX sources. See #2495 for a more detailed overview of the plan to port the WASI libc filesystem to Windows.
Add os_clock_res_get and os_clock_time_get in platform_api_extension.h, and implement them in posix like platforms and windows platform.
Implement the necessary os_ filesystem functions to enable successful WASI initialization on Windows. Some small changes were also required to the sockets implementation to use the new windows_handle type. The remaining functions will be implemented in a future PR.
Refactoring the clock functions to use WASI types so we can simplify the code and remove some unnecessary boilerplate. See #2637 (comment) for details.
Since C++20, std::memory_order is defined as an enum class so requires explicit casting to an int when adding enum values. See https://en.cppreference.com/w/cpp/atomic/memory_order.
Most of the WASI filesystem tests require at least creating/deleting a file to test filesystem functionality so some additional filesystem APIs have been implemented on Windows so we can test what has been implemented so far. For those WASI functions which haven't been implemented, we skip the tests. These will be implemented in a future PR after which we can remove the relevant filters. Additionally, in order to run the WASI socket and thread tests, we need to install the wasi-sdk in CI and build the test source code prior to running the tests.
To allow anything to depend on WASI types, including platform-specific data structures, move the WASI libc filesystem/clock interface into `platform_api_extension.h`, which leaves just WASI types in `platform_wasi.h`. And `platform_wasi.h` has been renamed to `platform_wasi_types.h` to reflect that it only defines types now and no function declarations. Finally, these changes allow us to remove the `windows_fdflags` type which was essentially a duplicate of `__wasi_fdflags_t`.
UWP apps do not have a console attached so any output to stdout/stderr is lost. Therefore, provide a default BH_VPRINTF in that case for debug builds which redirects output to the debugger.
`platform_common.h` already has a declaration for BH_VPRINTF so we can get rid of the one in `platform_internal.h`. Also add some explicit casts to avoid MSVC compiler warnings.
|
@wenyongh the build seems to fail due to reasons not related to the PR itself, I suspect it might just be an interim github actions issue. The failing check is |
Yes, I restarted it, now it runs successfully. |
|
@loganek I have merged this PR since we have done carefully review in the |
|
Sounds good, thanks! |
victoryang00
pushed a commit
to victoryang00/wamr-aot-gc-checkpoint-restore
that referenced
this pull request
May 27, 2024
…si-libc-windows The implementation is already in a stage where it's possible to compile WAMR with wasi libc enabled and run wasi modules without errors.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We propose merging the
dev/wasi-libc-windowsbranch with it's current state. The implementation is already in a stage where it's possible to compile WAMR with wasi libc enabled and run wasi modules without errors.There's still quite a few wasi functions that are not implemented (mainly around filesystem, sockets and poll_oneoff) but I don't think that's a blocker and I suggest we continue development of that in the main branch (e.g. to avoid further merge conflicts).
@wenyongh let me know what are your thoughts on this and if there's anything you'd like us to do before we merge the dev branch into main.