Re: [cdt-dev] catchpoints design

[Elena Laskavaia <ELaskavaia@xxxxxxx>]

We are kind of going in circles there (see discussion page). I will ask 
bigger audience their opinion about the subject.

There is two approaches of implementing event breakpoint (aka catchpoint):
1) For each event type supported by backend create new breakpoint type. 
This can done by using platform debug extension mechanism for 
breakpoints. For each type implement property page and action dialog for 
adding them. Number of actions would be same as number of supported 
events (or we may group some). In case of gdb we looking at around 10 
events. (10 Add X breakpoint actions). CDT UI have to fixed to support 
breakpoints which are not implementing one of currently supported 
subtypes (such as ICLineBreakpoint)
2) Implement new subtype ICCatchpoint. This type would have 2 
attributes: event id and argument expression. New breakpoint type would 
be "catchpoint" and will be contributed from cdt debug core, as well as 
its attributes. UI would have one extra action Add Event Breakpoint 
which opens dialog with drop down event selection. The only problem is 
how debug model plugin contributes event types to it. I suggested to use 
special extension point that allow to contribute new event type for 
Catchpoint breakpoints specifically.

Technically we can implement both: fix CDT to implement correct support 
for expendable breakpoints and implement 2, and when debug model can 
decide which option to pick..

So any ideas on preferred way?


Pawel Piech wrote:
> Thank You Elena for writing up the proposal.  I added a companion 
> discussion page to it: 
> http://wiki.eclipse.org/Talk:CDT:_Debug:_Catchpoints_support, and I 
> added my comments there.  I hope that the discussion page could be 
> used to gather the comments on the proposal in a more organized 
> fashion than just the email replies.
>
> BTW, if you add the proposal page to your watch list you can be 
> notified of whenever it changes.
>
> Cheers,
> Pawel
>
> 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...
>>
>> 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
>>   
>