ref-fvm
ref-fvm copied to clipboard
Switch to maintained WASM instrumentation library
Switch from parity-wasm (now unmaintained https://github.com/paritytech/parity-wasm/pull/334) to wasmparser (https://crates.io/crates/wasmparser) and wasm-encoder (https://crates.io/crates/wasm-encoder).
This means re-implementing our instrumentation logic, unfortunately. But I'd rather not maintain parity-wasm.
See https://github.com/filecoin-project/ref-fvm/issues/668, https://github.com/filecoin-project/ref-fvm/issues/602.
Given that this "works" right now, we can probably target M2.2 here.
you can assigned this issue to me, i would try to resolve this during isolation
Stay sane! And good luck!
@Stebalien confirm that this stack overflow check work can across multiple contracts?
instrument_functions(&mut ctx, &mut module_info)?; //inject calls in function body but calldirect not check
thunk::generate_thunks(&mut ctx, &mut module_info)?; //inject the export function that be called by other actor
right?
We don't track stack height across calls.
The code is written this way because it instruments the code before and after every function call (instrument_functions). However, it can't put any code before or after a call into an exported function because that call comes from outside of the module. So it instead replaces exported functions with "thunks" (small wrapper functions) that run a bit of stack accounting code before calling the actual function.
There is an inter-contract stack limit, but that's a fixed limit of 1025 calls.
@Stebalien finished a draft version, all units and bench tests have passed. but the performance will definitely be lower than the old version. because wasmpaser/encoder can't directly modify the original file.
many code basically follow, wasmparser parses the [u8] and got a section reader, make a section builder variable, read a elementsfrom the section reader, edits the element, and finally adds the elements to the builder.
because wasmpaser/encoder can't directly modify the original file.
parity-wasm doesn't do this either, right? I mean, in both cases, we:
- Take the original file, parse it into some structured representation.
- Apply a set of transforms.
- Write it back.
Implemented.