Typing Control-C in Terminal app causes an interrupt signal that should enter the DPPC debugger but this only worked once since the signal handler never returned. Even if the signal handler reenabled the signal somehow, it calls enter_debugger recursively which is strange since the earlier calls to enter_debugger would never return.
Now the signal handler just sets a flag (power_on) which can be used to exit any loop (emulator loops, stepping loops, disassembly loops, dumping loops).
Main always calls enter_debugger now which calls the ppc_exec loop. The power_on flag will exit the ppc_exec loop to return to the debugger. Recursion of enter_debugger is eliminated except for calls to loguru's ABORT_F.
An enum power_off_reason is used to indicate why the power_on flag is set to false and to determine what happens next.
The TLBEntries allow converting virtual guest address to virtual host address but there's no easy way to get a guest physical address for debugging purposes.
Add a phys_tag field to fix that.
So that you don't see identical messages "Could not restore NVRAM content from the given file."
Instead, one will mention nvram.bin and the other will mention pram.bin.
Entering a blank command causes the last command to repeat. This doesn't make sense for the following commands:
help, quit, regs, context, printenv, setenv, nvedit, amicint, viaint.
If debugging with Xcode using Terminal.app for the console, Terminal.app may send empty lines to the dingusppc debugger while resizing the Terminal.app window and it will do this forever.
As a workaround, use std::cin.clear() to clear the input buffer before getline and loop until the terminal window size is not changing or the input line is not empty.
Take 2 of 587eb48f61. We now implement
this at the SDL level, which works cross-platform and allows us to
ensure that the guest never gets the Control-G event.
