| Re: [cdt-dev] catchpoints |
|
You may also want to take a look at bug 212316. It has a patch for
platform that allows the user to change the breakpoint type that is
created with a double-click in the editor. It was too late (or too
much ) for platform in 3.4, but I am going to press for this feature in
3.5. Plus, there is another feature of CDT breakpoints which allows them to have target-specific attributes. See bug 211533. I don't know if you will be able to use it directly for catchpoints, because they will require entirely new breakpoint types, but it may give you ideas for design. In general, I think this is a very difficult problem (enabling breakpoint creation actions based on context), because breakpoints can be created before a debug session is active. A rather simple solution may be to create a new command set for these new breakpoint actions and have this command set disabled by default. Cheers, Pawel Mikhail Khodjaiants wrote: All action should use "visibleWhen" to check if catchpoints are supported in general by the underlying context. I also think event types can be contributed via an extension point, but this is open for discussion, of course. -----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia Sent: Tuesday, April 08, 2008 3:21 PM To: CDT General developers list. Subject: Re: [cdt-dev] catchpoints This is the most tricky part. Short answer is for gdb is close to impossible to do. For example to know if gdb support catchpoints you not only need to start gdb but you also have to start program. I was thinking making ui (i.e. Add catchpoint... dialog) always show up and let backed return not supported operation in attempt to use particular unsupported event catchpoint. As what is showing up in the dialog as events: I think we let debugger plugin to contribute events, so technically if debugger does not contribute anything it won't show up. Mikhail Khodjaiants wrote: |