Community
Participate
Working Groups
Build Identifier: I20110127-2034 I'm using the new pin and clone feature that Patrick Chuong is working on. I'm working with build I20110127-2034 with the following pin overlay patch applied to it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=334566 After I create two instances of the disassembly view, pin one of the views to core 0 and the other view to core 1, run both cores, and then halt both cores, I sometimes see one disassembly view get updated but the other one is blank. I looked at the disassembly source code and I think what's happening is that when I run both cores, the disassembly view gets a debug context changed notification with each core's IExecutionDMContext context. The disassembly view's DisassemblyBackendDsf class has a fTargetContext variable which gets set to null because the context is not a IFrameDMContext (the cores are running so there is no IFrameDMContext context available). When both cores halt, the disassembly view gets a debug context changed notification for core 1 with the top-level frame context, and fTargetContext is set to this value. Then the DisassemblyBackendDsf's handleEvent() gets called with a ISuspendedDMEvent parameter for each core. Core 1's disassembly view gets updated because fTargetContext is set to a frame context. Core 0's disassembly view ignores the ISuspendedDMEvent event because fTargetContext is set to null. I think one way to fix this is that when the cores are run and DisassemblyBackendDsf's setDebugContext() is called with an IExecutionDMContext object, setDebugContext() could set fTargetContext to this value instead of setting it to null. Then when the suspended event comes in, it could get the active top-level frame using this execution context, and then get the diassembly for this frame. Reproducible: Sometimes Steps to Reproduce: 1. launch a dual-core debug configuration 2. open a disassembly view 3. pin the disassembly view to core 0 4. clone the disassembly view 5. pin the new disassembly view to core 1 6. run both cores 7. halt both cores. After both cores halt, I see in the Debug view that the top-level frame in core 1 is the active view and the disassembly view for core 1 is updated. The disassembly view for core 0 is empty. I can force the disassembly view to update by clicking on the top-most stack frame for core 0.
Created attachment 189211 [details] patch to discover stackframe Norman, can you try this patch? I think the issue is that the disassembly blanks out when you select the thread node in the debug view. But why can't it use the first stackframe element? Also, it doesn't seem right to have the view blank out when the target is running, where thread node is available and can be use to retrieve disassembly data. Why prevent the disassembly view from showing disassembly data for target that can access memory when it is running? i.e target that supports realtime mode. With this patch, there is still an issue that needs to be resolve to retrieves additional disassembly from the backend when you scroll up and down, but this is a separate issue.
I tried the patch and the pinned disassembly views update properly now. Thanks!
Tony, can you take a look at the patch?
Why not use IStack.getTopFrame() instead of retrieving the whole stack? That should be much better in terms of performance. I don't understand why you set dmContext to the current fTargetFrameContext in case of an exception. That does not seem right.
I didn't see the getTopFrame(), I'll make the change. The reason to use the current frame context is to prevent target not be able to retrieves stackframe while it is running or under other conditions. However, for other target that support realtime target access, this is not an issue. If this is not the right thing to do, do you have other suggestions?
(In reply to comment #5) > The reason to use the current frame context is to prevent target not be able to > retrieves stackframe while it is running or under other conditions. However, > for other target that support realtime target access, this is not an issue. If > this is not the right thing to do, do you have other suggestions? This sounds like a completely different issue. In fact the disassembly blocks updates while the target is running with a reason. In the WR version this has been made a preference which is off by default. Maybe we should do the same in open source? In any case please open a new bug for that.
TI debugger also have similar preference to enable target access while target is running. I'll file a new bug for this request. Aside from the target access while running issue, there are couple things that I am not sure about in order to address this bug correctly: 1. Do we want to blank out the view when target is not accessible? I think the cached disassembly instruction should not be clear, only new request should fail. i.e the view will not be able to scroll. 2. If the view is blank out when target is not accessible, does the pinned view needs to re-populate when target is suspended without selecting the thread (stackframe) that it is pinned to? This approach doesn't seem like it follows the other debug views, where each view changes it's input from debug context change event.
(In reply to comment #7) > 1. Do we want to blank out the view when target is not accessible? I think the > cached disassembly instruction should not be clear, only new request should > fail. i.e the view will not be able to scroll. No, but this is about changing the context selection and if we switch to a context which is not accessible, we should not stay at the previously selected, except the new context is the same as the old.
I just found another problem with the patch. Following AssertionError occurs when selecting a thread from a different session, because the services tracker used to query the stack service is for the previous session. java.lang.AssertionError at org.eclipse.cdt.dsf.service.DsfServicesTracker.getServiceReference(DsfServicesTracker.java:177) at org.eclipse.cdt.dsf.service.DsfServicesTracker.getService(DsfServicesTracker.java:222) at org.eclipse.cdt.dsf.service.DsfServicesTracker.getService(DsfServicesTracker.java:207) at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyBackendDsf$2.execute(DisassemblyBackendDsf.java:175) at org.eclipse.cdt.dsf.concurrent.Query.run(Query.java:175) at org.eclipse.cdt.dsf.concurrent.ImmediateInDsfExecutor$1.run(ImmediateInDsfExecutor.java:41) at org.eclipse.cdt.dsf.concurrent.DefaultDsfExecutor$TracingWrapperRunnable.run(DefaultDsfExecutor.java:371)
Created attachment 190899 [details] Handles no debug context selection Right now, the disassembly view doesn't blank out if there is no debug context selected in the debug view. This patch addressed this issue and in the same time it blank out the pinned view when the pinned context resume. With this patch, the disassembly behavior is consistent with the fix in this bug 338472. Is this the right thing to do?
(In reply to comment #10) > Created attachment 190899 [details] > Handles no debug context selection > > Right now, the disassembly view doesn't blank out if there is no debug context > selected in the debug view. This patch addressed this issue and in the same > time it blank out the pinned view when the pinned context resume. With this > patch, the disassembly behavior is consistent with the fix in this bug 338472. > > Is this the right thing to do? This does not dispose the previous backend. I have committed a different fix. I also noticed that the "No debug context" content description is no longer displayed when the disassembly blanks out. This seems to be caused by PinDebugContextActionDelegate.updatePinContextLabel(DebugContextPinProvider).
Toni, thanks for the fix. I also fixed the "No debug context" issue has well. Norman, can you verify the latest fixes in HEAD? Note that the disassembly view will not automatic update after the core is suspended, you have to select the stackframe to populate the view.
Patrick, I grabbed the latest CDT sources from the head and I see the disassembly view blank out correctly. If a disassembly view is pinned to a core and then I terminate the launch, I see the disassembly view is stilled pinned to the core and it shows the pinned context label instead of "No debug context." If I unpin the view, then I see "No debug context." Is this the expected behavior? Yup, I noticed that sometimes the pinned disassembly view doesn't update until I click on a stackframe. I guess your patch will need to be fixed to address Anton's issues with it first?
(In reply to comment #13) > If a disassembly view is pinned to a core and then I terminate the launch, I > see the disassembly view is stilled pinned to the core and it shows the pinned > context label instead of "No debug context." If I unpin the view, then I see > "No debug context." Is this the expected behavior? Yes, this is one of the requirements . > Yup, I noticed that sometimes the pinned disassembly view doesn't update until > I click on a stackframe. I guess your patch will need to be fixed to address > Anton's issues with it first? The view shouldn't update until you select the stackframe, this is how the other view work as well. View refresh is driven from the debug selection, so as actions within the view. We can't just refresh the view itself when core is suspended, view actions also needs to be update as well, and all updates are generated from debug context change event. The two patches in this bug should be obsoleted with the Toni's fix and 338472.
