search

openMSX / debugger

31 stars 15 forks source link

Inconsistent "break" status between GUI and internal debugger #173

Closed Colpocorto closed 1 year ago

Colpocorto commented 1 year ago

Steps to reproduce:

-Open any OpenMSX instance and a Debugger instance. -Connect the Debugger UI to the OpenMSX instance -Execute "debug break" at the OpenMSX console or click the "break" button. The debugger will get into "step-by-step" mode. -Execute "debug cont" at the OpenMSX console. The debugger should exit the "step-by-step" mode but that never happens (the "break" button remains disabled and the "run" button remains enabled).

pvmm commented 1 year ago

This would require openMSX to tell directly to the debugger running/break state changes, just like it already does with breakpoint/watchpoint/conditions state updates. Do you find that useful in any way? Because I guess most people don't need to control running/break state from two different interfaces. Since typing "debug cont" is more annoying than clicking a button.

MBilderbeek commented 1 year ago

@pvmm But the debugger already subscribes to the status update, which should indicate the break status, right?

$ grep openmsx_update src/* -r
src/DebuggerForm.cpp:   comm.sendCommand(new SimpleCommand("openmsx_update enable status"));

Is it possible that this event isn't properly handled?

What about something like attached patch? unbreak.patch.txt

Colpocorto commented 1 year ago

This would require openMSX to tell directly to the debugger running/break state changes, just like it already does with breakpoint/watchpoint/conditions state updates. Do you find that useful in any way? Because I guess most people don't need to control running/break state from two different interfaces. Since typing "debug cont" is more annoying than clicking a button.

But this feature used to work fine in the past! It must be some kind of regression introduced in the new releases.

pvmm commented 1 year ago

Created PR #178.