Re: [platform-debug-dev] SUSPEND_RESUME event, Was: debug view features

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

Darin Wright wrote:

> platform-debug-dev-admin@xxxxxxxxxxx wrote on 10/25/2004 12:31:41 PM:
>
>  
>
> > > > 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)?
> > >
> > >
> > >
> > >      
> > 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.
> > -Pawel
> >
> >    
>
> OK, I don't quite understand the use case. The original comment says "... 
> when the user is stepping and is only interested in seeing the IP 
> move...". If the user has requested a step, why has the thread since 
> resumed? Is this something specific to the debug architecture?
>
>  
Sorry, I don't think I explained enough of the background:
We have a two layered implementation of the debugger, where the eclipse 
debug model implementation calls into the lower layer (let's call it 
debug engine) which does the thread state tracking etc.  For various 
reasons some of our views do not use the debug model, and interface 
directly with the debug engine, so coalescing of suspend/resume events 
is important for us even at this level.
To make stepping smoother, we allow the user to keep clicking on the 
step button even if the target is running (stepping), and we queue up 
the step requests in the debug engine (not in debug model 
implementation).  When the debugger engine receives a suspended event, 
it checks the step queue and then it completely cancels out the 
suspended and resumed events, but it issues a separate event 
"suspended-resumed".

> The debug view currently does *not* display source when a thread suspends 
> but resumes before the debug view updates. I.e. when processing the 
> suspend event the "LaunchViewEventHandler" does not process the suspend 
> event if the thread responds "false" to "isSuspended()". 
Then perhaps no new event in the debug model is needed at all, it could 
be enough to just change the above behavior so that the debug view DOES 
open the editor even if the thread is already resumed... to give the 
user a visual indicator of something happening :-)
An issue related to this which I didn't mention yet to avoid confusion, 
is when should the IP be erased.  Currently the IP is erased when the 
resumed event is received by LaunchViewEventHandler.  It would probably 
be more visually appealing if the IP was erased when the step timeout 
expires and the stack frames are repainted with a running icon.  Perhaps 
in this context, updating the IP even if the thread is in running state 
makes more sense.

Cheers,
Pawel

> This should mean 
> you don't have to worry about coalecsing the suspend/resume events in your 
> model.
>
> Darin
>
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>