|
You're right. Disregard my previous e-mail, I was too tired
at the end of the day.
As for "trial and fail" I may not work in some cases. It is possible to
set a breakpoint in gdb at an invalid address and gdb will not complain.
But run fails as long as the breakpoint is set. Probably this is one
of the cases Daniel mentioned.
I agree about the problem, but not so much about the solution
:-) For common functionality, there should be common UI. We just
need to figure out a proper mechanism for hiding functionality that is not
available, which is in a way what Eclipse is all about...
Mikhail
Khodjaiants wrote:
Yes. Do you think it is possible? I have heard
many complains about UI components (views, actions, etc) that are visible but
not supported.
Do you mean to say that these breakpoint
should not be in org.eclipse.cdt.debug.core/ui?
Mikhail Khodjaiants
wrote:
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:
Speaking seriously, please make sure the UI for this functionality
doesn't appear if a backend doesn't support it.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
--
IMPORTANT NOTICE: The contents of this
email and any attachments are confidential and may also be privileged. If
you are not the intended recipient, please notify the sender immediately and
do not disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.
_______________________________________________
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
|
