Re: [cdt-dev] catchpoints design

[Phil Muldoon <pmuldoon@xxxxxxxxxx>]

Elena Laskavaia wrote:
> The behavior is up the backend... If debugger stops all threads for 
> example when
> backend whould detect it and send appropriate events to model and UI. I 
> don't think we should restrict or define behavior associated with this. 
> User can add Breakpoints action as for regular breakpoints though...
>   

Sure! Not restricting at all. If the debugger always blocks by default, 
so be it. You can't do anything but what what the debugger decides. But 
if it allows configurable behavior perhaps we should look at that, see 
if this is feasible. This is a subtle but important point, I think. As 
catchpoints are "behavioral breakpoints" they can trigger far,  far more 
often than the conventional user-set code breakpoints - which are a bit 
more predictable. For example, a catchpoint on a syscall enter, and 
syscall exit will trigger very often indeed. To block the thread every 
time would be a pain on the user.  In this case, you could tell the 
debugger just to continue automatically (and maybe log the event, or 
some other plug-in definable event).

Perhaps this is beyond the scope of an initial implementation, or indeed 
the CDT. But having experience in this area,  catchpoints (or observers 
in Frysk parlance) really run the board on how they can be handled.

I think the proposal is great, but I think spending a few iterations 
exploring this would be at least a learning experience, and at best 
catch some implementation corner cases

Best Regards

Phil

> Phil Muldoon wrote:
>   
> > Elena Laskavaia wrote:
> >
> > Hi Elena,
> >
> >     
> > > I added catchpoints design wiki page
> > > http://wiki.eclipse.org/CDT:_Debug:_Catchpoints_support
> > > Please take a look, I want to keep it very simple but extensible.
> > > If we agree in general I can continue with details of implementation.
> > >  
> > >       
> > Thanks for this. It reads well.
> >
> > One thing I am unclear about is how the inferior is blocked or continued
> > when a catchpoint occurs. Is this behaviorally defined  via the observer
> > pattern, like it is in Frysk? For example ....  perhaps there is
> > catchpoint to catch signal emission from the inferior. How is the 
> > behavior defined on how to handle that catchpoint event?  Should the
> > task (thread) be blocked? Should it be noted, perhaps, logged and let to
> > continue? How rich of a model is one to implement here. If we could
> > explore this a little, I think it would help define what functionality
> > and modeling the CDT, and the Debugger Framework Model in general, want
> > out of the debugger.
> >
> > Regards
> >
> > Phil
> >
> >     
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >  
> > >       
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >     
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>