debugging/stepping

[oli-obk]

I'd like to use miri to step through code like in a debugger. At first I thought it would make sense to restructure miri so the interpreter ends up looping over an iterator that does the actual processing. But now I wonder if it would make sense to insert "hooks" into random places inside the interpreter, which a caller to the interpreter could attach to. So basically the interpreter runs in a thread and whenever it encounters a hook-place, it checks for a hook and if one is there, starts interacting with it.

The hook has a few options available:

• obtain information about a stack frame
• obtain the stack frame list
• read the memory behind a pointer
• execute an arbitrary MIR statement.
• stop the interpreter
• allow the interpreter to continue
• add/remove hooks
• step to the next hook-place

Possible hook-places:

• reaching a file:line (requires checking spans in the interpreter)
• changes a memory location gotten during another hook-processing
• interpretation errors (unknown intrinsic, overflow, UB)

What do you think?

[Ericson2314]

What's wrong with the iterator method? It seems strictly more general to me. If we had the async stuff that has been proposed night not even be so painful!

[oli-obk]

What's wrong with the iterator method?

We'd have to keep state inside miri. This way the state is the current execution of miri.

[Ericson2314]

Hmm, I'll have to actually look at the code and not just follow the issues to see what you mean :).

[eddyb]

AFAIK the main problem is Operand::Constant, which can occur in a myriad of locations, but requires evaluating more MIR. This is where generators would be nice.

Could do constant instantiation ahead of time before running code in the function, I suppose?

[oli-obk]

I think it's mainly a question of whether to restructure the code around the iterator model (thus requiring state + possibly re-loading of some information at each step) or keeping the current structure (which is optimized for interpretation) and simply adding the various points where the code can be stopped.

Restructuring around an iterator model is possible, but it limits the possibilities (breaking at arbitrary points during interpretation, not just at statements) and creates unintuitive control flow.

[oli-obk]

miri has been restructured around a stepping model. No measurable performance loss in some micro benchmarks.