EVM opcode: breakpoint

[axic]

Motivation

To speed up debugging, if a breakpoint is expected there is no need to step through execution, but can safely stop at the breakpoint.

Specification

A new opcode, BREAKPOINT is introduced at 0xfd.

Option 1:

A virtual machine if run in debugging mode, should stop execution when encountering this instruction, otherwise it should ignore it.

Option 2:

It stays as an invalid instruction in a deployed contract, but special debugging EVM implementations are allowed to support it.

Alternatively, another good name is DEBUG.

[Arachnid]

Can't debuggers set breakpoints using external information? This method would require changing the code every time you want to add or remove breakpoints.

[gcolvin]

The C++ VM has hook for a callback function that can be and I think is used for debugging. @yann300 ?

[yann300]

Yes. Though that would mean to readd the JavaScript interpreter I guess...

[gcolvin]

@yann300 I don't really understand, as the hook must already be used by any debugger that wants to single-step, inspect stack and memory, etc. The hook gets called for every instruction executed, so it can stop when the desired program counter is reached. But I do get that performance takes a hit. If we do go with the breakpoint instruction there would need to be a way to call into the running VM to modify the code, and probably a way to get the other information the hook provides. Just stopping doesn't help if you can't inspect the state of the program.

[yann300]

Calling the running VM to modify the code on the fly sounds interesting.
When the user is is debug session, the bytecode could be updated as the user is writing new solidity code that is about to be executed... (not sure if it completely doable).
As remix is in JavaScript that would mean to add a JavaScript interpreter in a c++ code that could call JavaScript callback right? or maybe I misunderstood something....

[gcolvin]

I only meant modifying a single opcode with this new BREAKPOINT opcode.

[yann300]

yes i know, I was just wondering if we could also update the bytecode as the user is writting. Some IDEs do that.

[nmushegian]

A general principle of ethereum and blockchains is if it can be done off-chain, do it off chain.

[kumavis]

0xfd is claimed by revert

[GNSPS]

I really like the idea of having a breakpoint opcode. I feel that option 2 kind of defeats the purpose of standardizing this though, I would go with 1.

Would it make sense to mimic x86 arch and have an interrupt opcode with a single byte param?

The VM, if run in debugging mode, would then have the opportunity to have stored routines given different interrupt values. (And we could have a single-byte version for the breakpoint interrupt much like INT 3 in x86.

[insipx]

I like the idea of mimic-ing x86 functionality along with UNIX Opcodes. On UNIX, the process of breakpoints looks something like:

Create Breakpoint

    Compute location of the break point
    Read byte that was there and save it.
    Put 0xCC byte there (int3 opcode). If program is ptraced, executing int3 will freeze it.

disabling Breakpoints:

    Disable breakpoint (write back old instruction)
    Run single step (PTRACE_SINGLESTEP)
    Enable breakpoint (write int3)
    Continue (PTRACE_CONT)

It could look similar in EVM too.

[gcolvin]

It might be more useful to consider something more general like the Java Debug Wire Protocol. The debugger asks the VM to set a breakpoint, single step, or whatever and it's up to the VM to make it happen however it likes.

[insipx]

@gcolvin Huhm, didn't think of that. Definitely a potential solution, but I worry about it's extendability. Would this be more of a solidity feature, or can it be extended to apply to other languages (IE: Viper)? I'm not totally familiar with the Java Debug Wire Protocol. Would it require making changes to the VM for every language that is to be debugged with?

I think the con of doing it the UNIX-way would be the potential need to implement a compile option for debug symbols in order to be able to step-over and into solidity code rather than the underlying assembly. However, once an interface is created, it may be easier to create debug symbols for other languages rather than modify an interface similar to the Java Debug Wire Protocol.

[gcolvin]

It's not a language feature, it's a wire protocol that all JVMs have to implement. It could be optional if we wanted. That way any Java debugger can be used for either VM. Another advantage is that debuggers (Eclipse, JSwat, etc.) aren't linked to the VM, but connect via a socket. It's stood up to years of use and extension by now.