Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Debug actions are registered twice

>So, the activation code must be in DSF, or somehow in cdt.debug.ui, but not in DSF-GDB

By activation code are you referring to EvaluationContextManager?

If so, how about we make it the responsibility of the debuggers to set the org.eclipse.cdt.debug.ui.debuggerActive property? Just because the current context is IDMVMContext, we can’t assume the debugger actually implements these actions.  The actions shouldn’t appear unless the debugger explicitly wants them to.  It does this by setting the appropriate system property. 

This may cause some confusion for vendors who are integrating with DSF, but the alternative would be to always display these actions for a DSF-debugger and then popping up the annoying “action is not available” dialog box when user selects them for a debugger that doesn’t implement them.  I personally prefer the former approach (I don’t think actions should be displayed in the UI if they’re not available).

 

- Navid

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Tuesday, April 27, 2010 1:52 PM
To: 'CDT General developers list.'
Subject: RE: [cdt-dev] Debug actions are registered twice

 

> How could the problem remain if we’re registering the actions once? They’re not going to be re-created. 

 

You're right.  I guess the problem will be different and not as bad.  Say you install your debugger and DSF-GDB,

then those actions will be visible for your debugger.  But if you install only your debugger, the actions

won't be visible anymore.  It may be even a little worse than that if plugin activation does not load

the DSF-GDB code until you run a DSF-GDB session.

 

So, the activation code must be in DSF, or somehow in cdt.debug.ui, but not in DSF-GDB

 

Marc

 

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mehregani, Navid
Sent: Tuesday, April 27, 2010 1:39 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Debug actions are registered twice

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


Back to the top