Add example of compiling wat and running with wasmtime#141
Merged
kubkon merged 1 commit intobytecodealliance:masterfrom May 12, 2019
Conversation
kubkon
reviewed
May 11, 2019
docs/WASI-tutorial.md
Outdated
|
|
||
| ;; Write 'hello world\n' to memory at an offset of 8 bytes | ||
| ;; Note the trailing newline which is required for the text to appear | ||
| (data (i32.const 8) "hello word\n") |
Member
There was a problem hiding this comment.
Suggested change
| (data (i32.const 8) "hello word\n") | |
| (data (i32.const 8) "hello world\n") |
Member
|
Looks great to me! Thanks! One thing though, did you know that you don't need to compile WAT to WASM in order to run it in wasmtime? You could actually simply run: Perhaps it'd be good to add in the tutorial as well, next to What do you think? |
AlanFoster
force-pushed
the
add-example-of-compiling-wat-and-running-with-wasmtime
branch
from
03e687b to
d0a9fa0
Compare
Contributor
Author
|
@kubkon Awesome; I've jigged things around to show running |
Member
|
LGTM! Thanks again! |
kubkon
pushed a commit
that referenced
this pull request
Nov 7, 2019
* Add versions to the crates. This is needed for publishing on crates.io. * Add a few Cargo.toml attributes to make the crates.io page friendlier.
grishasobol
pushed a commit
to grishasobol/wasmtime
that referenced
this pull request
Nov 29, 2021
This also allows `Instruction` to be `Copy`, which massively speeds up `<Instructions as Clone>::clone` since it can now just `memcpy` the bytes using SIMD instead of having to switch on every single element. I haven't looked at the disassembly of `InstructionIter::next` yet, it could be that there are even more improvements yet to be gained from either: * Only doing work on `BrTable` (this might already be the case depending on the whims of the optimiser) * Using `unsafe` to make it a noop (we really don't want to do this, obviously, since it means that `Instructions` has to be immovable)
mooori
pushed a commit
to mooori/wasmtime
that referenced
this pull request
Dec 20, 2023
zkasm: i64.extend32_u
dhil
added a commit
to dhil/wasmtime
that referenced
this pull request
Mar 26, 2024
…codealliance#141) Currently, external tools that want to inspect our stack while running wasmfx code, such as `gdb`, `lldb` and `perf`, need to rely on the DWARF information that wasmtime produces. In particular, we have some hand-crafted DWARF directives in `crates/runtime/src/fibre/unix/x86_64.rs` that encode the parent-child relationship between continuations' stacks. Unfortunately, `perf` gets stuck when working on information recorded with `perf record --call-graph dwarf`, meaning that it is having issues with the DWARF-based backtrace frame information that wasmtime offers. Luckily, in generated code, wasmtime/cranelift use frame pointers to facilitate stack walking. However, these frame pointer chains are currently broken when crossing continuation stacks: Inside `wasmtime_fibre_start`, the "launchpad" sitting at the bottom of every fiber stack, it is not the case that the `RBP` register contains an address where we may load a frame pointer for the parent/caller. However, I realized that we can actually construct a fully working frame pointer chain by only making a few changes. The technical details are described in the comment at the beginning of `unix.rs` (featuring ASCII art!). With these changes in place, `perf` now shows perfect backtraces when invoked with `perf record --call-graph fp`. This method of recording should also have less overhead than the DWARF-based profiling approach. While this PR adds a lot of comments and re-organizes some code, the actual changes are small. Let `TOS` be the top of stack of a continuation, then: 1. At `TOS - 0x10`, we no longer store a *stack* pointer denoting the end of the stack frame where `wasmtime_fibre_switch` switched to us, but the *frame* pointer of the that stack frame of where `wasmtime_fibre_switch` switched to us. The difference between these two is always a constant offset, meaning that we can obtain one from the other. 2. At `TOS - 0x08`, we now store a fake return address, which is the address of `wasmtime_fibre_switch`. Thus, any stack walking tool sees that the "caller" of `wasmtime_fibre_start` is the `wasmtime_fibre_switch` in the parent continuation's stack, whose parent is in turn the function that `resume`-d us. These changes are basically for free: - In `wasmtime_fibre_switch`, all we need to do is some arithmetic to translate between frame pointers and stack pointers - I've slightly re-organized `wasmtime_fibre_init` for clarity, but the only extra work it does is storing a pointer to `wasmtime_fibre_switch` at `TOS - 0x08`. The only other change is one extra step of address arithmetic. - `wasmtime_fibre_start` remains logically unchanged, except for a small change to the `.cfi_` directives and we now source the value of TOS from a different register. --------- Co-authored-by: Daniel Hillerström <daniel.hillerstrom@ed.ac.uk>
avanhatt
pushed a commit
to wellesley-prog-sys/wasmtime
that referenced
this pull request
Oct 18, 2024
avanhatt
pushed a commit
to wellesley-prog-sys/wasmtime
that referenced
this pull request
Oct 18, 2024
Add support for fetching models containing unspecified values. With the addition of declared sorts in bytecodealliance#141, this broke the code that parses constants from SMT models. The backend solvers differ on how they implement this. This PR deals with the CVC5 format only, in which unspecified values are represented as something like `(as @Unspecified_0 Unspecified)`. Updates avanhatt#45
dicej
pushed a commit
to dicej/wasmtime
that referenced
this pull request
May 8, 2025
…e-set-poll Update ABI of `waitable-set.poll`
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Adding a simple hello world example of WASI to allow developers without any context to understand WASI at its simplest level.
Let me know your thoughts 👍