| [platform-debug-dev] SUSPEND_RESUME event, Was: debug view features for embedded debugging |
In our case that actually is the model event: The model receives a suspended event, but there is already a resume action queued. So currently, the model doesn't send out neither SUSPEND nor RESUME. IMO, the biggest problem with this suggestion is that after such event, the state of the thread would still be running, and as such it shouldn't return a stack frames, and the top stack frame would be needed by the debug view in order to update the IP. To avoid abusing the current IThread interface too much, I think we'd need a new interface that returns the last top stack frame, specifically for handling this event... and I see why you wouldn't find that appealing.2. DebugEvent.SUSPEND_RESUME event. In embedded debuggers especially retrieving and displaying data can be very expensive, especially when user is stepping and is only interested in seeing the IP move on the screen. To address this, we would like to add a debug event that would only be intended for the debug view, in order to update the IP annotations. I haven't fully thought through what other implications this might have so another method (rather than new event) of achieving the same ends might be more appropriate.Events are intended to describe what is happening in the debug model, rather than be used directly as UI flags. Thus, I would prefer to see a different solution. Perhaps this means that the debug view should simply have a mode where it does not broadcast selection changes (which drives other views, such as the variables view)?
-Pawel