Thanks
Dobrin
Hi ,
I'll be curious to find out whether you can observe this
implementation causing any problems, but I wouldn't expect it
to. The purpose of the suspended event listener is to
accelerate when the source lookup takes place. If we wait
until a debug context event to trigger a source lookup and
display, it means that we have to wait for the debug view to
process the suspended event, issue a select delta, then for
the viewer to process that delta, and to broadcast a debug
context changed event. All this adds up to a considerable
delay if we want a smooth stepping experience.
Normally, when user is stepping a thread rapidly, the
selection doesn't change much. I.e. it says on frame 0,
that's why this solution of retrieving active debug context
make sense. Otherwise, if the selection in debug view is
changing, then we should avoid updating the source display on
suspended event and wait for the debug context changed event
instead.
Cheers,
Pawel
On 05/17/2011 12:30 PM, Alexiev, Dobrin wrote:
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
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev