alloc free creates, memory import support, and more#3
Open
leon-thomm wants to merge 41 commits intosecure-foundations:mainfrom
Open
alloc free creates, memory import support, and more#3leon-thomm wants to merge 41 commits intosecure-foundations:mainfrom
leon-thomm wants to merge 41 commits intosecure-foundations:mainfrom
Conversation
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
Member
|
Hey! Glad to hear you're using a fork of rWasm for some of your research! Indeed upstreaming things would be good, and I'm open to merging a lot of these changes in. Unfortunately, a few things are going to keep me busy for the next few months to be able to do a proper review of the code just yet, but a few quick comments:
|
Author
|
Thank you for the feedback
done; I added a dependency for colored output
done
done |
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.
Hey 👋 at eth-easl we're working on a fork of rWasm which we're using in one of our research projects. I would like to upstream as much as possible, so I want to open the discussion on the changes. Feel free to provide feedback on any part.
This PR adds
--no-alloc--crate-namenotes on the changes to the code:
Vecfrom indirect function calls. If the optionno-allocis given, it now uses a newenumallocating an upper bound of space needed for the returns on the stack by considering the largest number of returns from any function in the compiled module.Boxto keep it "simple" with--no-alloc. AVecalready lives on the heap, and a&mut [u8]can too, but a memory of typemut [u8](--fixed-mem-size+ not imported memory) now necessarily lives on the stack.mem_type()function--no-allocrequires--fixed-mem-sizetrait MemoryType1parser.rsI think
parser.rssyntax could use some love, but I couldn't come up with a nice solution yet. Do you have ideas?I did some basic sanity checks after the changes but I didn't test thoroughly. I added a very basic integration test.2
Footnotes
notice that for a
Vec<T>-like type,Tshould probably beSized, which can't be dynamically dispatched (so noMemoryTypetrait objects) ↩I haven't tested WASI, but I didn't make WASI-specific changes. ↩