Skip to content

Use wast crate to emit / patch wasm binary file. #106

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

Closed
wants to merge 5 commits into from

Conversation

yurydelendik
Copy link
Contributor

WIP

The wast crate already has lots of data structures to do the job. The new wasmemit crate re-exports these and add AstReader to ingest the binary file.

I provided two use cases / tests (to replace function import and to replace memory type) to evaluate the solution.

Is it something we interested to have in wasm-tools?

@alexcrichton
Copy link
Member

Thanks for this! I'm a bit confused by the purpose of this crate though. With a name like wasmemit it sounds like this would be used as an API to generate a wasm file (e.g. section writers and whatnot). Instead though it looks like this is parsing a binary file directly into a wast AST?

Could you expand a bit more on what parsing a binary directly into an AST is needed for? For example it's "possible" today by printing to text with wasmprinter and then parsing that with wast, but I suspect it's surely slower than parsing the binary directly into an AST.

@yurydelendik
Copy link
Contributor Author

yurydelendik commented Sep 28, 2020

Instead though it looks like this is parsing a binary file directly into a wast AST?

Bulk of the work is done at wast though the crate mostly deals with parsing. I did not want to move wast AST into wasmemit at this moment, but it is a suggested place for it (plus all Encode stuff). Maybe ?

what parsing a binary directly into an AST is needed for? ... but I suspect it's surely slower than parsing the binary directly into an AST.

Indeed. It is mostly for a wasm binary patching, such as replace/add memory or imports without wasting too much memory on AST.

The tracking of id is a key here too, so when types/imports/functions are changed, the instructions will be encoded with new indices. It will be harder to do it in a text format.

@alexcrichton
Copy link
Member

My (naive) expectation for a crate which allows writing wasm would be one that doesn't require an AST to be constructed. Instead you'd have a bunch of glorified wrappers around Vec<u8> to allow the consumer to flexibly represent whatever it has. For example wast would use its own AST to directly call various methods in this hypothetical writer crate, and walrus would use its different AST to write a wasm blob.

I'd ideally like to move those crates to a common emission crate, but I wouldn't want to do it, for example, if something like walrus had to construct an extra AST since that could slow it down relative to where it is today.


Transforming wasm in general is pretty tricky due to indices, but that's where crates like walrus try to help by making index management a breeze. I'm not sure if there's a great intermediary between walrus and writing wasm bytes yourself, though, as working with the AST of wast would probably feel quite clunky and clumsy (it was never designed for this sort of purpose)

@yurydelendik
Copy link
Contributor Author

Transforming wasm in general is pretty tricky due to indices

It was not that tricky with wast data structure Id -- and reader's purpose to generate these.

Alright, I'll keep it where it is now, as a WIP at my side.

dhil added a commit to dhil/wasm-tools that referenced this pull request Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants