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.
This PR adds tests for #2219 by changing the `compilation_on_android_ubuntu.yml` workflow.
The first run will take about two hours, since LLDB is built from scratch. Later, the build is
cached and the whole job should not take more than three minutes.
Core of the PR is an integration test that boots up vscode and lets it debug a test WASM file.
Fixes#2267.
This PR doesn't decrease the coverage, because every job is tested either per PR or
nightly run (instead of 2 times as it was before). Actually, it even increases it because
Android is tested with Ubuntu 20 now which was disabled before.
This PR adds LLDB formatters so that variables are human-readable when debugging
Rust code in VS Code. This includes Tuple, Slice, String, Vector, Map, Enum etc.
It also distributes a standalone Python version with LLDB. This solution enables high
portability, so Ubuntu 20.04 and 22.04 can for example still be supported with the
same build since glibc is statically linked in the Python build, also making it easier to
support more operating systems in the future.
Known Issues: Enum types are not displayed correctly.
For more details, refer to:
https://github.com/bytecodealliance/wasm-micro-runtime/pull/2219
Add nightly (UTC time) checks with asan and ubsan, and also put gcc-4.8 build
to nightly run since we don't need to run it with every PR.
Co-authored-by: Maksim Litskevich <makslit@amazon.co.uk>
- Translate all the opcodes of threads spec proposal for Fast JIT
- Add the atomic flag for Fast JIT load/store IRs to support atomic load/store
- Add new atomic related Fast JIT IRs and translate them in the codegen
- Add suspend_flags check in branch opcodes and before/after call function
- Modify CI to enable Fast JIT multi-threading test
Co-authored-by: TianlongLiang <tianlong.liang@intel.com>
Notably, this disables python scripting support on ubuntu:
* It isn't necessary for the primary purpose of this build. (that is, the vscode extension)
* It has been disabled in the macOS counterpart.
* It allows to use the same binary for 22.04 and 20.04. (note: 22.04 and 20.04 provide different versions of libpython)
In #1928 we added support for GCC 4.8 but we don't continuously test if it's
working. This PR added a GitHub actions job to test compilation on GCC 4.8
for interpreters and Fast JIT (LLVM JIT/AOT might be added in the future).
The compilation is done using ubuntu 14.04 image as that's the simplest way
to get GCC 4.8 compiler. The job only compiles the code but does not run any
tests.
Update wasi-libc version to resolve the hang issue when running wasi-threads cases.
Implement custom sync primitives as a counterpart of `pthread_barrier_wait` to
attempt to replace pthread sync primitives since they seem to cause data races
when running with the thread sanitizer.
`wasi-sdk-20` pre-release can be used to avoid building `wasi-libc` to enable threads.
It's not possible to use `wasi-sdk-20` pre-release on Ubuntu 20.04 because of
incompatibility with the glibc version:
```bash
/opt/wasi-sdk/bin/clang: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
(required by /opt/wasi-sdk/bin/clang)
```
- Implement atomic.fence to ensure a proper memory synchronization order
- Destroy exec_env_singleton first in wasm/aot deinstantiation
- Change terminate other threads to wait for other threads in
wasm_exec_env_destroy
- Fix detach thread in thread_manager_start_routine
- Fix duplicated lock cluster->lock in wasm_cluster_cancel_thread
- Add lib-pthread and lib-wasi-threads compilation to Windows CI
- Add timeout to CI WASI tests to avoid keeping CI node busy in case of
deadlock in thread tests
- Update wasi-testsuite commit used, after fix in wasi-threads proposal
https://github.com/WebAssembly/wasi-threads/pull/40
- CMakeLists.txt: add lib_export.h to install list
- Fast JIT: enlarge spill cache size to enable several standalone cases
when hw bound check is disabled
- Thread manager: wasm_cluster_exit_thread may destroy an invalid
exec_env->module_inst when exec_env was destroyed before
- samples/socket-api: fix failure to run timeout_client.wasm
- enhance CI build wasi-libc and sample/wasm-c-api-imports CMakeLlist.txt
Upgrade the version of related toolkits:
- upgrade llvm to 15.0
- upgrade wasi-sdk to 19.0
- upgrade emsdk to 3.1.28
- upgrade wabt to 1.0.31
- upgrade binaryen to 111
And upgrade the CI scripts, sample workload build scripts, Dockerfiles, and documents.
Publish an extension to the visual studio marketplace using a secret token.
This allows for automation to take place because downloading and installing
the extension is a manual process so it'd be simpler if the extension was
published automatically through the visual studio marketplace.
The original CI didn't actually run wasi test suite for x86-32 since the `TEST_ON_X86_32=true`
isn't written into $GITHUB_ENV.
And refine the error output when failed to link import global.
