forked from secure-foundations/rWasm
-
Notifications
You must be signed in to change notification settings - Fork 0
Dandelion dev #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
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
and I changed how the names section parser reads the type, while the original implementation seems correct under the current number of subsection types, run!(32) is confusing because it should really only read one byte
I saw no good reason why some parsers should be defined within the generate! macro, and others not. For simplicity, I moved them all outside.
not a cosmetic change, will redo on another branch
Cosmetic parser changes
fix old run_manual! usage
Eliminates all uses of alloc::Box and alloc::Vec when --no-alloc is chosen. The main difficulty with removing Vec is the fact that wasm functions have multi-returns, so when calling indirect we don't know how many returns come back. This commit solves it by allocating as much space on the stack as needed for the highest possible number of returns when calling indirect. There are other non-stack-based solutions, especially the tinyvec crate allows static heapless vector functionality without usage of unsafe.
makes it a lot nicer to consume the rWasm output from another program
Turns out we only need a panic handler in no_std crates if they are dynamic libraries, which shouldn't be necessary for the crate generated by rWasm.
This makes WasmModule::new() const, which allows for static initialization, which is important in heap-less environments. It also makes access functions to global constant exports const, so global export constants can also be statically accessed, which is often useful as well.
will need this for incoming changes
This option allows passing a bytes array slice to the wasm module which will be used for the wasm memory. Since this must have a fixed size, this is currently only possible in combination with --fixed-mem-size. Such a reference to an external chunk of memory requires lifetime annotation, which is a bit messy in the printer, I might try to come up with a macro which relaxes syntax boilerplate for code generation.
the option is implicit if the WASM module imports its memory
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.
This PR adds
--no-alloc
--crate-name
notes on the changes to the code:
Vec
from indirect function calls. If optionno-alloc
is given it now uses a new enum which will allocate an upper bound of space needed for the returns on the stack.Box
to keep it "simple" with--no-alloc
.Vec
already lives on the heap, and a&mut [u8]
can too.mut [u8]
(--fixed-mem-size
+ not imported memory) now necessarily lives on the stack.--no-alloc
requires--fixed-mem-size
mem_type()
functiontrait MemoryType
Vec<T>
-like type,T
should probably beSized
, which can't be dynamically dispatched (so noMemoryType
trait objects)Vec
with a custom memory allocator provided by the user, but I wouldn't expect anything to land in stable soon.const
so they can be used forstatic
definitions.parser.rs
I think
parser.rs
really needs some syntactic simplifications but I couldn't come up with a nice solution yet. I did some sanity checks but didn't test thoroughly, I think rWasm should get some CI tests.