VM: Support for better debugging and state manipulation

[pinkiebell]

As a user, I need better support for debugging and state manipulation.

For vm.runCode, I need the ability to:

• define initial stack values before the code runs
• define initial memory before the code runs
• define the program counter to start execution at a specific opcode

Also nice to have would be the ability to get information about memory reads or writes inside
step events, this can be as simple as

memoryRead: {  'ptr': 2, 'len': 4 }
memoryWritten: { 'ptr': 5, 'len': 9 }

Another feature I thinking about is the ability to 'pause' and 'resume' an execution.

[pinkiebell]

Question is do wan't something like a debugging options-object for these calls or just expand the previous optional arguments?

[s1na]

@holgerd77 @axic Would it make sense to extract runCode to an EVM library which doesn't have many dependencies, but uses an API like EEI to access data? This could potentially go a long way towards supporting other VMs, mocking them or for debugging purposes.

[holgerd77]

On a first thought I would probably say: yes, circling in @cdetrio since this is pretty close related to a potential future eWASM kernel integration, also @vpulim.

[holgerd77]

Actually these ideas proposed here are so simple that I do not understand why we need 7 years to implement/consider them. 😂

@jochem-brouwer can you please take over responsibility of this issue and decide if we want to give at least the "initial stack values/inital memory" part of the suggested additions 2-3 hours of implementation time and add to the EVM.runCode() API:

export interface EVMRunCodeOpts extends EVMRunOpts {
  /*
   * The initial program counter. Defaults to `0`
   */
  pc?: number
}

(you can also very much decide for sure that we do not want right now out of non-followed-up demand and rather simply close here)

[jochem-brouwer]

I'm not really sure if we want to add this. On one side, I have had the general idea of allowing arbitrary RunState to be injected in the EVM and "just run it". This could be useful where you first do a evm.runCall and then want to run it later again, but then you don't start at the begin of the call but just copy over the state at the point you want to continue. This sounds nice, but for complex situations this thus means that you have to copy over the entire state. That is: also the revert cache, the touched accounts, the current storage key/values, the account balances, etc. (otherwise you will likely end up in a different state). So for realistic situations this would need careful input generation to ensure the EVM behaves as we expect.

For the case raised here, set an initial stack and program counter: this is easy to do, but the only use case I would see is to test simple opcodes (test ADD for instance). In case of more complex situations, above reasoning applies (setup entire EVM state). So I am actually not sure how useful this simple addition is. Adding the more useful situation (thus with the entire state copied over) sounds somewhat easy-ish to do, but I think we will run into nasty edge cases and I'm not sure if that is worth it.

I think for most, if not all, situations setting up the pre-environment and then running a runCall would suffice (but prove me wrong!).