wasm-tools icon indicating copy to clipboard operation
wasm-tools copied to clipboard

Published 20 hours ago • verified publisher icon bytecodealliance

Make wasmparser no_std again

Open yurydelendik opened this issue 5 years ago • 5 comments

There is still intent to support "no_std" feature for this crate. There is no need to support allocation hungry API such as WasmParser/WasmDecoder, so it will be beneficial to make this legacy API under feature -- the section readers is more performant API and has to be used at this moment.

TODOs:

  • [ ] Make WasmParser and friends optional via feature (and/or deprecate)
  • [ ] Cleanup sections readers to not use dynamic memory Box, Vec, HashMap

I think that will allow us to be no_std without depending on alloc or hashbrown crates.

yurydelendik avatar Feb 24 '20 18:02 yurydelendik

What API are you imagining for things like BrTable::read_table where we allocate a Box<[..]>? Instead taking a user-provided callbacks-style trait to incrementally report the entries and let the trait implementor decide if/how to allocate?

fitzgen avatar Feb 24 '20 19:02 fitzgen

What API are you imagining for things like BrTable::read_table where we allocate a Box<[..]> ?

We already have BrTableIterator to read it incrementally. Is it possible improve it further to allow optimal Iterator::collect?

yurydelendik avatar Feb 24 '20 20:02 yurydelendik

  • [ ] convert validate logic into something that can be done without Vec (can be possible with preallocated buffers or cache-read?)

yurydelendik avatar Feb 26 '20 13:02 yurydelendik

While I like the proposal of going back to no_std this kind of conflicts with the other proposal to use T: Read as parser input instead of byte slices. We could work around that by creating another trait that is similar to Read but works in no_std.

My PR does some initial work on T: Read parsing and could in theory be also used as stepping stone for this proposal since it moves the allocating parts to the user side.

Robbepop avatar May 18 '20 21:05 Robbepop

In case anyone requires no_std support for the wasmparser crate: I am maintaining a no_std fork for embedded environments here: https://crates.io/crates/wasmparser-nostd

Robbepop avatar Sep 12 '22 14:09 Robbepop

For anyone interested I've opened https://github.com/bytecodealliance/wasmtime/issues/8341 which is for Wasmtime but would extend to wasmparser since it's a dependency and would be required as well.

alexcrichton avatar Apr 11 '24 20:04 alexcrichton

Done now in https://github.com/bytecodealliance/wasm-tools/pull/1493, so closing.

alexcrichton avatar May 09 '24 20:05 alexcrichton