Thanks Pawel,
This suggestion is a good one, but it is not sufficient, at least not for our debugger with a slow target connection.
I did further investigation I here is one interesting find:
DsfSourceDisplayAdapter
@DsfServiceEventHandler
public void eventDispatched(final IRunControl.ISuspendedDMEvent e) {
….
Display.getDefault().asyncExec(new Runnable() {
public void run() {
Object context = DebugUITools.getDebugContext();
if (context instanceof IDMVMContext) {
final IDMContext dmc = ((IDMVMContext)context).getDMContext();
if (dmc instanceof IFrameDMContext && DMContexts.isAncestorOf(dmc, e.getDMContext())) {
doDisplaySource((IFrameDMContext) dmc, page, false, true);
}
}
Considering that everything is asynchronous what guarantees that DebugUITools.getDebugContext() will return the new FrameContext when the Runnable is executed at the UI thread?
Requesting the stack frame from the Stack service it asynchronous so it might not be constructed then?
Dobrin
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Tuesday, May 17, 2011 12:34 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] stepping synchronized with the source editor PC marker updates
While the generic DSF behavior is as intended, I think there is still room for some fine tuning. And still other fine-tuning may depend on a specific debugger implementation.
For example one thing I notice is that SteppingController.getPendingStepCount(), is used in DSF to prevent a selection change in editor from being made if a new step is pending to be executed. But I also see that in Wind River's product, we have some additional tuning (that Toni or Randy added) where the VariableVMNode also doesn't issue a content update delta if there are steps pending as in the snippet below. Another thing to experiement would be the depth of the step queue.
Cheers,
Pawel
@Override
public void buildDelta(final Object event, final VMDelta parentDelta, int nodeOffset,
final RequestMonitor requestMonitor) { if (event instanceof ISuspendedDMEvent && !shouldWaitHandleEventToComplete()) { DsfExecutor executor = getSession().getExecutor();
executor.execute(new DsfRunnable() { public void run() { IExecutionDMContext exeDmc = ((ISuspendedDMEvent) event).getDMContext();
IRunControl rc = getServicesTracker().getService(IRunControl.class);
SteppingController sc = (SteppingController) exeDmc.getAdapter(SteppingController.class);
if (rc != null && !rc.isStepping(exeDmc) && (sc == null || sc.getPendingStepCount(exeDmc) == 0)) { parentDelta.setFlags(parentDelta.getFlags() | IModelDelta.CONTENT);
}
requestMonitor.done();
}
});
return;
...
On 05/16/2011 02:59 PM, Alexiev, Dobrin wrote:
Initially I thought so, but the user experience is not exactly what I expected.
If there are no opened additional views the experience is pretty good - I have the F5 key pressed down and the source editor updates - the PC is being updated - the user is seeing the PC is progressing.
As far as I have few other (somewhat slower windows) registers, memory, variables - when I keep the F5 key pressed down, I don't see the PC indicator moving smoothly in the source editor with maximum speed.
BTW, I don't want to delay the update to the other views, I just want to make sure when the user has the F5 key down he sees the PC indicator being updated.
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Monday, May 16, 2011 5:36 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] stepping synchronized with the source editor PC marker updates
Actually what you described is what DSF does by default: i.e. minimum
step interval preference is 0, and wait to update views is unchecked.
However, we did not go as far as delaying updates to data views. Such
that the data views will request data from the debug engine upon a
suspended event, but the run control commands will not wait for the
views to finish updating. For details look at SteppingController and
its supporting cast.
On 05/16/2011 02:11 PM, Alexiev, Dobrin wrote:
I need a little more control:
In my case I want the source editor to be somewhat different than the others views( memory, variables, registers, etc.).
I want to ensure the source editor has opened/updated the PC indicator after the step, but I don't want to wait for all the data in the registers, memory, variables to update before I allow the next step.
How can I achieve that?
Thanks
Dobrin
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Thursday, May 12, 2011 8:13 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] stepping synchronized with the source editor PC marker updates
I think you want
Preferences->Run/Debug->View Performance
and don't use the option "Wait for views to update after every step"
The "Minimum interval between steps" could be useful for you as well on that page.
Marc
________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexiev, Dobrin [dalexiev@xxxxxx]
Sent: May 12, 2011 4:46 PM
To: CDT General developers list.
Subject: [cdt-dev] stepping synchronized with the source editor PC marker updates
Hello,
Is there a way in DSF to make sure the editor PC indicator updates before other views go ahead and update themselves when stepping?
I want the users to be able to perform the next step as fast as the PC indicator in the source editor updates.
If there are other views opened ( Registers, Memory, Variables, Expressions, Disassembly, etc.) their updates should not be blocking the stepping.
Thanks
Dobrin
_______________________________________________
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
_______________________________________________
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
