[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] catchpoints design
|
Would you want to see "Add Catchpoint" even if your debugger doesn't
support them?
-Pawel
John Cortell wrote:
Because of the sheer number of catch point types and the fact that you
don't always have a context by which to filter capabilities, I think
approach 2 is the way to go.
John
At 01:32 PM 4/14/2008, Elena Laskavaia wrote:
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
>>
>
_______________________________________________
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
