AntelopeIO/eos-vm

Synthetic - Teaching Item

larryk85 opened this issue · 4 comments

larryk85 commented

Compile EOS-VM into a small program of your creation,

The program should do the following:

  • Via CMake utilize EOS-VM

  • Load a WASM program

  • Define the interface for the WASM program (for simplicity you can use the interface for EOS smart contracts apply to reuse that as an entry point via CDT).

  • Create a set of host functions:

    • print_string(const char* s, size_t len) : print a given string via a pointer and a length. (This will require a span, look at LEAP host functions for reference).
    • exit(int code) : this should immediately exit the running program and return the error.

    Any additional ones you want to make is worth additional golden banana stickers.

Create a visitor that extends https://github.com/AntelopeIO/eos-vm/blob/main/include/eosio/vm/interpret_visitor.hpp that captures debug data:
- functions that were called (these will only be an ordinal and not a name) and frequency of those calls.
- Total number of memory operations executed.

You should create a new 'backend' with your visitor to be used in the same manner as the normal interpreter or JIT backend.

larryk85 commented

You will also need to look to CDT's EOSIOLIB for how to expose the host functions so that you can call them. Hint, they look a lot like extern "C", an eerie amount like them.

jolly-fellow commented

Does requirement "Total number of memory operations executed." means that all 25 memory instructions should be intercepted and counted?

Answer from @larryk85 : each type of the memory operation should be counted separately.

jolly-fellow commented

Update for the educational task from @larryk85:

For anyone who wants additional work for this.

One thing of note is that you can implement both static and dynamic analysis for this and have your tool produce both. I.e. one that counts the number of memory ops without running the wasm (i.e. static count) and one that is used via extending the interpret_visitor.

An additional task for you and others who want more would be to analyze the running WASM and output a listing of WASM pointers to material addresses (i.e. fully materialized on the native side), additional points if you can output the WASM line number information of those memory operations.

  • super stars if you get through this by Monday *

Review what "tail calls" are https://en.wikipedia.org/wiki/Tail_call. Analyze the WASM in the same way that you would write your analyze either statically or dynamically "find" the locations for sites where tail call optimizations would be available.