Support to get `wasm_memory_type_t memory_type` from API
`wasm_runtime_get_import_type` and `wasm_runtime_get_export_type`,
and then get shared flag, initial page cout, maximum page count
from the memory_type:
```C
bool
wasm_memory_type_get_shared(const wasm_memory_type_t memory_type);
uint32_t
wasm_memory_type_get_init_page_count(const wasm_memory_type_t memory_type);
uint32_t
wasm_memory_type_get_max_page_count(const wasm_memory_type_t memory_type);
```
Add aot binary analysis tool aot-analyzer, samples:
```bash
# parse example.aot, and print basic information about AoT file
$ ./aot-analyzer -i example.aot
# parse example.aot, and print the size of text section of the AoT file
$ ./aot-analyzer -t example.aot
# compare these two files, and show the difference in function size between them
$ ./aot-analyzer -c example.aot example.wasm
```
Signed-off-by: ganjing <ganjing@xiaomi.com>
- Add new API wasm_runtime_load_ex() in wasm_export.h
and wasm_module_new_ex in wasm_c_api.h
- Put aot_create_perf_map() into a separated file aot_perf_map.c
- In perf.map, function names include user specified module name
- Enhance the script to help flamegraph generations
Last bit missing from #3206: demangling of function names (useful for wasm
generated from Rust for instance) using `llvm-cxxfilt`.
Before this PR:
```text
0: abort
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/panic_abort/src/lib.rs:85
1: _ZN3std3sys4wasi14abort_internal17h50698daab05bf73bE
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/wasi/mod.rs:181
2: _ZN3std7process5abort17h6bc522b6749f17cfE
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/process.rs:2278
3: _ZN3std5alloc8rust_oom17h452ad5ba6cebff96E
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/alloc.rs:364
```
After:
```text
0: abort
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/panic_abort/src/lib.rs:85
1: std::sys::wasi::abort_internal::h50698daab05bf73b
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/wasi/mod.rs:181
2: std::process::abort::h6bc522b6749f17cf
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/process.rs:2278
3: std::alloc::rust_oom::h452ad5ba6cebff96
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/alloc.rs:364
```
Update the `addr2line` script so that:
- line info is printed in a more convenient format, e.g.
```
0: c
at wasm-micro-runtime/test-tools/addr2line/trap.c:5:1
1: b
at wasm-micro-runtime/test-tools/addr2line/trap.c:11:12
2: a
at wasm-micro-runtime/test-tools/addr2line/trap.c:17:12
```
similar to how Rust prints stack traces when there's a panic. In an IDE, the user
can conveniently click on the printed path and be redirected to the file line.
- a new `--no-addr` argument can be provided to the script
It can be used in fast interpreter mode (that is not supported by the script otherwise)
or with older wamr versions (where the stack trace only had the function index info
and not the function address). In that case, `wasm-objdump` is used to get the function
name from the index and `llvm-dwarfdump` to obtain the location info (where the line
refers to the start of the function).
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
every pre-compiled function beginning, which is not compatible
with addr2line
- Temporarily disable the deque test for the VS Code extension, as the
Rust formatter seems to malfunction after a recent VS Code update.
- Add configuration for iwasm host managed heap size, allowing users
to flexibly `malloc` memory. This also fixes the current bug that when
default size is 0, it can't run and debug.
- Apply coding style formatting for WAMR IDE source code and add a
format check for it in CI.
- Update document and some screenshots.
Implement the GC (Garbage Collection) feature for interpreter mode,
AOT mode and LLVM-JIT mode, and support most features of the latest
spec proposal, and also enable the stringref feature.
Use `cmake -DWAMR_BUILD_GC=1/0` to enable/disable the feature,
and `wamrc --enable-gc` to generate the AOT file with GC supported.
And update the AOT file version from 2 to 3 since there are many AOT
ABI breaks, including the changes of AOT file format, the changes of
AOT module/memory instance layouts, the AOT runtime APIs for the
AOT code to invoke and so on.
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.
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
The `DebugConfigurationProvider` was overwriting configurations provided
in `launch.json`. In particular, this for example prevented from specifying a
custom port for the debugger.
Example `launch.json`
```
{
"configurations": [
{
"type": "wamr-debug",
"request": "attach",
"name": "Attach Debugger",
"stopOnEntry": true,
"attachCommands": [
"process connect -p wasm connect://127.0.0.1:1237"
]
}
]
}
```
Co-authored-by: Ben Riegel <benjuri@amazon.com>
This should allow users to use the vscode extension on ubuntu 20.04.
After https://github.com/bytecodealliance/wasm-micro-runtime/pull/2132 ,
our lldb binary for 20.04 works on ubuntu 22.04 as well.
On the other hand, lldb for 22.04 has no chance to work on ubuntu 20.04.
(because of glibc version requirement.)
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.
Add more types for attr_container, e.g. uint8, uint32, uint64
Add more APIs for attr_container for int8, int16 and int32 types
Rename fields of the union 'jvalue' and refactor some files that use attr_container
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.
Download and install the WAMR patched LLDB binary on vscode extension activation.
This allows the user to download the packaged .vsix file, where the activation script
should handle determining what LLDB binary they should use, and install it in the
correct location.
Fix a widespread bug named CVE-2007-4559, which is a 15 year old bug
in the Python tarfile package. By using extract() or extractall() on a tarfile
object without sanitizing input, a maliciously crafted .tar file could
perform a directory path traversal attack. This patch essentially checks to
see if all tarfile members will be extracted safely and throws an exception
otherwise.
Add CIs to enable the release process of a new version of WAMR,
and build and publish the binary files when a version is released,
including iwasm, wamrc, lldb, vscode-extension and wamr-ide for
Ubuntu-20.04, Ubuntu-22.04 and MacOS.
And refine the CIs to test spec cases.
Related to https://github.com/bytecodealliance/wasm-micro-runtime/issues/1418.
Suppress hadolint warnings for pinning version.
This is because these warnings are for reproducible builds.
But for development and CIs, ordinary case developers have to use the latest packages.
