Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Ecilpse Debug views Refresh

The StateChangeEvent logic may need some enhancement in the different VM nodes to properly refresh in some cases.
This was recently investigated here:
 
Using the StateChangeEvent still looks like the correct way to go, although its support is not complete yet.
You could try to fix it for CDT.
 
Another approach that was just added to CDT is to cause a re-selection of the debug context.
This was also done in
You can look at the new class RefreshableDebugCommand.java
 
As for the getting the container context, the usage of MIProcesses.UNIQUE_GROUP_ID
is not proper because you are not specifying a real process.  With multi-process support
you should actually specify which process you want to refresh.
 
However, it sounds that in your case, you want to refresh the entire view not just one
process.  So you probably just need to send the StateChangedEvent with the ICommandControlDMContext.
But this is where the missing logic for that event happens; you'll need to listen for that event in LaunchRootVMNode.
 
I hope this helps.
 
Marc
 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Charankumar Siripuram
Sent: Tuesday, February 26, 2013 5:13 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Ecilpse Debug views Refresh

Hi Eclipse-Team,

 

We had got same issue while debugging targets with our eclipse based debugger. After getting target connection and downloading the program to target, all debug views need to be updated. We have tried “org.eclipse.cdt.dsf.debug.ui.viewmodel.launch.StateChangeEvent “ as Pawel suggested. But, view are not getting refresh.

 

Please find the below snippet, which I have tried:

 

IMIProcesses procService =  dsfTracker.getService(IMIProcesses.class);

IMIContainerDMContext containerDmc =           procService.createContainerContextFromGroupId(

                dsfTracker.getService(IGDBControl.class).getContext(), MIProcesses.UNIQUE_GROUP_ID);

 

StateChangedEvent event = new StateChangedEvent(containerDmc);

activeDsfSession.dispatchEvent(event, null);

 

Is the way of getting IMIContainerDMContext instance is proper? I couldn’t find solution for this. Any suggestions from you will be appreciated.

 

 

Regards,

Charan

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Friday, February 22, 2013 10:23 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Ecilpse Debug views Refresh

 

Hi Eduard,
I think you are looking for the org.eclipse.cdt.dsf.debug.ui.viewmodel.launch.StateChangeEvent.  This even was added to deal with basically this kind of an issue.

Cheers,
Pawel

On 02/21/2013 07:46 AM, Bechtold, Eduard wrote:

Hello dear Eclipse-Team,

 

Since long we have been using Eclipse for debugging our targets. We have also implemented many Plug-Ins for internal purposes.

Some of our Plug-Ins use gdb commands to change Information on our targets.

We have encountered one problem when changing something that affects the current debug context with gdb commands.

·         In one of our Plug-Ins we change the current program counter, stack pointer… and after these changes we would like Eclipse to notice it. We need Eclipse to refresh like when receiving suspend event from gdb after hitting a breakpoint, when debugging.

·         In an other Plug-In we change one of our target settings, which is called thread awareness. When it is turned off we only return the active thread to the debugger (for faster debugging). Otherwise we return information of all running threads. Here we have the same problem as above, we need some mechanism to tell Eclipse it should refresh again on current debug context.

Currently we are using many workarounds only for that purpose. For example inserting a breakpoint and jumping that address. Other workarounds contain even replacing instructions with nops and letting the target run over them, so that the target suspends again and the gdb sends the suspend trigger for refresh of Eclipse.

So my question is:

·         Is there some way to trigger a refresh of the internal Eclipse Debug views (including debug, registers, variables, expressions view…)?

      (For example by sending an event with the active debug context, and/or active launch)

 

We would really appreciate your help with our Eclipse refresh problem, so we can get a rid of a whole bunch of workarounds.

 

With best regards,
Eduard Bechtold


Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
Factory Automation
I IA AS FA DH AMB 2
Werner-von-Siemens-Str. 50
92224 Amberg, Germany
mailto:eduard.bechtold.ext@xxxxxxxxxxx

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 

 
***** Confidentiality Statement/Disclaimer *****

This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.
The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.

Back to the top