Thanks John/Marc!
>You'll notice that all the classes
that actually run the actions are the ones from cdt.debug.ui and are
retargettable.
>I believe the only issue was the
EvaluationContextManager. Now that I think about it, maybe I could have
re-used
>the registration of those actions of
cdt.debug.ui by simply re-using the same system property instead of creating a
new one.
Yes, the actions are retargettable. I don’t see
any reason why we shouldn’t be able to use the same actions declared in
cdt.debug.ui.
>But even with this improvement, the
problem would remain because DSF-GDB check for IDMVMContext.
How could the problem remain if we’re registering the
actions once? They’re not going to be re-created.
I’ve filed bugzilla https://bugs.eclipse.org/bugs/post_bug.cgi
as a general placeholder to clean up the code. Marc/John, feel free to
add yourself to the CC list.
Thanks,
- Navid
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Tuesday, April 27, 2010 1:24
PM
To: 'CDT
General developers list.'
Subject: RE: [cdt-dev] Debug
actions are registered twice
I believe the reason they appear twice is
that the DSF-GDB debugger will set the
org.eclipse.cdt.dsf.gdb.ui.debuggerActiveproperty to true as long as
the current debug context is an
IDMVMContext. This is done in EvaluationContextManager (the DSF-GDB
version). So, when any other DSF-based
debugger is has the current debug context,
the DSF-GDB class will stil turn on this property. My bad.
One solution would be to move this EvaluationContextManager
down to DSF and make it available to all DSF-based debuggers.
The reason I couldn't use the existing one
EvaluationContextManager, is that I needed to check if the debug context was a
DSF or CDI context,
but, unlike CDI, DSF does not have an
interface I could check for in cdt.debug.ui.
You'll notice that all the classes that
actually run the actions are the ones from cdt.debug.ui and are
retargettable.
I believe the only issue was the
EvaluationContextManager. Now that I think about it, maybe I could have
re-used
the registration of those actions of
cdt.debug.ui by simply re-using the same system property instead of creating a
new one.
But even with this improvement, the
problem would remain because DSF-GDB check for IDMVMContext.
So, we can clean this up a bit and move
EvaluationContextManager down to DSF.
Or does someone have another idea?
Marc
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Tuesday, April 27, 2010
12:00 PM
To: CDT
General developers list.; CDT
General developers list.
Subject: RE: [cdt-dev] Debug
actions are registered twice
Indeed, cdt.debug.ui seems like the most intuitive home for actions
that are not gdb-specific, but I suspect the problem is that they were not
designed to be retargetable and so each debugger needs to contribute its own
set. The actions that come from platform
debug (run, stop, step, etc) are retargetable. However, the Debug
actions you're seeing duplicated are contributed by CDT.
Marc added these actions to DSF-GDB via
https://bugs.eclipse.org/bugs/show_bug.cgi?id=300096
and then I believe Nokia abstracted them out to be common to base DSF(so EDC
could use them).
You'd have to ask them if there's a reason (other than lack of time) why we
didn't make these common retargetable actions in CDT. It's possible such a
mechanism isn't yet available in CDT debug and, again, that there was just no
time to introduce it for Helios.
But, at the end of the day, the current approach is working. Forget the fact
that they're registered more than once. They aren't appearing more than once
even when you have simultaneous CDI and DSF sessions going. Again, why it's
happening in your case needs further investigation.
John
At 10:27 AM 4/27/2010, Mehregani, Navid wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_496565EC904933469F292DDA3F1663E602CB2C5F9Edlee06enttico_"
Yes,
Ive noticed that too. Likely has something to do with the fact
that our debugger is based on DSF.
I have no idea where org.eclipse.cdt.dsf.gdb.ui.debuggerActive
property is set and cleared. May be (just a guess), this property doesnt
get cleared when we launch our custom debug session?!
Im really curious whether its necessary to register these actions
twice.
Other non-GDB-based-debuggers should be able to make use of these contributions
so Im not sure if it makes sense to move them to the common gdb
plugins. It sort of makes sense for them to be in cdt.debug.ui.
- Navid
From:
cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Tuesday, April 27, 2010
11:13 AM
To: CDT
General developers list.; CDT
General developers list.
Subject: Re: [cdt-dev] Debug
actions are registered twice
I wonder if the new common gdb plugins I added a few weeks could save the day
here.
One thing I question, though....launching a DSF-GDB session and then a CDI-GDB
session doesn't result in these actions appearing twice. Why is it happening
when your debugger is in the mix?
John
At 10:00 AM 4/27/2010, Mehregani, Navid wrote:
Content-Language: en-US
Content-Type: multipart/related;
boundary="_004_496565EC904933469F292DDA3F1663E602CB2C5F5Fdlee06enttico_";
type="multipart/alternative"
Im just wondering, is there a need
to register debug actions Run to Line, Move to Line, Resume at Line, and Add
Watch Expressiontwice in the editors context menu?
These actions are registered once in org.eclipse.cdt.debug.ui and again under
org.eclipse.cdt.dsf.gdb.ui. The former plug-in looks for
org.eclipse.cdt.debug.ui.debuggerActivesystem property and latter plug-in looks
for org.eclipse.cdt.dsf.gdb.ui.debuggerActiveproperty in order to display the
actions.
We have a proprietary debug engine based on DSF. It doesnt use GDB at
all. The problem occurs when I start a DSF-GDB debug session, terminate
it, and start our custom DSF-based debug session. This will result in the
debug actions getting registered twice:
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
