Skip to content

Orca next steps

Jump to bottom
ahuoguo edited this page Jul 9, 2024 · 7 revisions

To play with init_generator:

  • add_global
  • add_function (add type) For instr_generator, orca wants:
  • a way to attach injected code with the InstrumentatType Enum (like a Vec<Body> field) Think more about constant folding, what we need to provide for fold_expr (seems like what the original func_info is for). What orca basically needs is to look up 0 for a call 0 (target_fn_type target_imp_name ) You want something like
curr_instr.inject_before().block(|block| {
  //block instructions
})

or

curr_instr.inject_before().i32_const(0).i32_const(0).i32_add();

Discussion on alt curr_instr.save_args() -> [(LocalId, ValType)] curr_instr.inject_alt().if().instr().else().restore_args() restore_args([(LocalId, ValType)])

API design

Global/Local

For LocalId GlobalId (global.id()?) (see VarAddr in whamm/src/verifier/types.rs), we are currently not relating indices and the id (we are doing this implicitly). We want to abstract away as its own struct.

Globals -> Vec<Global> 
Global -> GlobalType, InitExpr, Index

Visitor

We want a more granular visitor, visit_fn and visit_insturction, each should support a ComponentIndex, ModuleIndex, FunctionIndex, InstrIndex, abstract away next()

Component -> Number of Modules
Module -> Number of Functions
Function -> Number of Instructions

We want to abstract away enumerate to our own counters

  • What do we return on next()? The info we need to know is basically 1. location, 2. Current Instruction

Consider:

wasm:bytecode:call:alt /
    target_fn_type == "import" &&
    target_imp_module == "ic0" &&
    target_imp_name == "call_perform"
/ {
    new_target_fn_name = "instr_inject_synchronous_fault";
}

Whamm should be looking up the target_fn_type. (look up 5 in the call 5 in app.wasm)

Code Injection API

before() -> marks current as InstrumentBefore and initialises empty vector
instr() -> adds instruction to the vector

pub fn before() {
    curr_loc.1 = InstrumentBefore(vec![])
}
pub fn i32(val: i32) {
    curr_loc.1.0.push(i32(val))
}

For blocks, .block().stmt1().stmt2().end() may work better? Consider nested blocks, .block().block()....end().end(), compared to .block(.block()) this doesnt make sense

Maybe check out BreWasm

Clone this wiki locally