Community
Participate
Working Groups
Suppose you have variable "int i" in your program. During debug, 1. Add "memory monitor" on "&i". Then you should see value of "i" in the memory pane. 2. Change the value of the memory word for "i" in the memory pane. 3. Now you can see the value of "i" in Variable View does not change accordingly while it should. Similarly the change is not reflected in Expression View if you have expression "i" in it. On the other hand, manual change to value of "i" in Variable View is not propagated to memory view. In general, this is an issue on how to synchronize value display between Variable, Expression, Memory and Register views.
Are you using CDT? I believe this this a CDT problem. When the memory block is changed, CDT should fire a change events on its variables, expressions and registers since they can all potentially changed. Similarly, when user change the value of a variable, CDT needs to fire a change event on the memory block to ensure that the Memory View is updated. Thanks... Samantha
Yes, I'm using CDT. And I also tend to think it's a CDT bug. But I was not sure so I logged it against the platform. I've changed "Product" of this entry to "CDT".
The synchronization between the Memory and Variables views has been fixed in 3.0.2. The problem still exists for the Expressions view.
As to the problem with Expression View, I believe it's easier to handle now with bug #125783(https://bugs.eclipse.org/bugs/show_bug.cgi?id=125783) fixed in platform.
(In reply to comment #4) > As to the problem with Expression View, I believe it's easier to handle now > with bug #125783(https://bugs.eclipse.org/bugs/show_bug.cgi?id=125783) fixed in > platform. We'll see. The problem is that we don't have access to IWatchExpression to notify it that something has changed. Actually, the problem occurs only for the top level elements of the view. If expression is a pointer to a structure, the members of the structure are updated.
Created attachment 65708 [details] Ling's partial fix to the bug
I created a patch to partially fix the bug. It makes CDT behavior in line with JDT. Namely after a var is changed, on next redraw of the Expression view (e.g. after stepping, or when the view is uncovered from background), the change will show up in the view. The remaining problem (with both CDT & JDT) is: Due to platform bug, the change will not show up in Expression View until the view is redrawn . In other words, if the Expression View is at the front (not covered) when the variable is changed, the change won't be reflected in the view.
Ling, back in February, I contributed a mechanism in CDT to cause a change in the memory view to propagate to the variables view and registers view (not sure at the moment if the same holds true for the expression view). See 172508. If that doesn't handle all your uses cases, you may want to look at expanding on that mechanism. It does require a CDI client to implement a new interface.
(In reply to comment #8) John, I noticed your addition. My patch is to make sure the expressions listen to and handle variable change event. I tried implementing your new interface of ICDITargetConfiguration3 in our CDI plugin and it surely works. Actually there are more pending issues in this category, say, variable change should also be propagated to Memory View, but we don't want variable & memory block listen to each other and ends up in infinite notification loop. Anyway, I plan to investigate more on that later.
Actually, this whole matter of something in one view affecting others is quite messy. Here's another scenario. User changes a value in the Registers view that affects one or more variables. The other way is easier to handle; the CDI client knows what register a variable is associated with, so if the user changes the variable value, the client can send a corresponding change notification for the affected register. But the opposite is much trickier. And there are even more complicated scenarios. Seems to me in most cases, the only way to provide dependable synchronization between some of these views is to ask for a complete refresh. For example, the client would need to tell CDT: if the user changes a register value, all bets are off in the Variables view. Re-fetch all elements. This is brutally inefficient, but it seems to me the coordination and logic required to avoid it (and still provide dependably synchronization) is unreasonable for some debugger engines. An alternative is to give the user the ability to do a re-fetch and refresh in a view. If he suspects he's done something in one view that has invalidated the display in another, he at least has the ability to tell the debugger to update its view.
My understanding of the discussion now is that we hold off on this change while Ling looks at using the new support John added to cover the case where the Expressions view (and probably others) need to respond to changes in the Variables view. Let me know if that's not correct.
(In reply to comment #11) John's addition is to make sure any change in memory view is propagated to variable view & register view, whereas mine patch is to make sure variable change in propagated to Expression view. So Ken, it's fine you commit my patch which is at least a step forward. My discussion with John is mainly about how to the broader scope issue, namely how to sync all debug data views when user changes something in one view.
OK, I applied the patch and will mark this case fixed.
