Community
Participate
Working Groups
I'm not sure if I've filed this under the right component, but if I switch to using the gdb-mi debugger (by specifying a standard process launcher for the configuration) then the problem described below does not occur. I'm seeing this behaviour in 8.1.0, 8.1.1 and the nightly kepler builds. Steps to reproduce : 1) After having built a C project, attempt to debug the project using the GDB DSF launcher. 2) Open up the 'Registers' view and scroll through all registers (this is to ensure their values get loaded) 3) modify one of the accumulator registers (eg. set rax to 11) 4) scroll to eax/ax and note that the 'value' column in the tree viewer for those registers haven't been updated (they will not be 11) 5) either edit-click the values or view the values in the detail pane for eax/ax to see that it has in fact been updated correctly for those UI elements (they will be 11).
Created attachment 231335 [details] Patch (git-formatted) Dispatching an IGroupsChangedDMEvent seems to solve this issue for me. This event is handled in RegisterGroupVMNode as a content change. I'm not sure if the upcoming changes to CDT 8.2.0 (Kepler) regarding synchronization of views include the Registers view, but if they don't, this small change should resolve the issue for now.
I tried the solution and it works well, The only suggestion I have is to use IRegistersChangedDMEvent instead of IGroupsChangedDMEvent, This will adjust the scope of the change accordingly and be ready when register groups are supported, The change could look as shown below. Would you push the change to Gerrit ? IRegistersChangedDMEvent event = new IRegistersChangedDMEvent() { @Override public IRegisterGroupDMContext getDMContext() { final MIRegisterGroupDMC groupDmc = DMContexts.getAncestorOfType(dmc, MIRegisterGroupDMC.class); return groupDmc; } }; // Fix Bug 400840 getSession().dispatchEvent(event, null);
Thanks for the feedback. I've submitted this to Gerrit at https://git.eclipse.org/r/#/c/13084/ .
I had a discussion with Mark Khouzam and he raised the concerned that raising the event for RegistersChanged will trigger a refresh on all registers as we scroll through the view. So the patch will fix the issue but will introduce an inefficiency that needs to be addressed. Looking at the command sequence from the Standard debug (CDI), we can see that it uses a MI command to find out the indexes of the registers that changed i.e. [1,369,334,325,939] 1605-data-list-changed-registers [1,369,334,325,940] 1605^done,changed-registers=["0","74","94","110"] So it is possible to introduce a more robust solution where individual register updates triggers data-list-changed-regisers from the MI/GDB interface and then fire individual Register Changed events which will limit the number of updates. Do we take this patch and create a new bug to track the missing part or do we modify the solution?
(In reply to comment #4) > Do we take this patch and create a new bug to track the missing part or do > we modify the solution? I think it is too late in the cycle to start using a new MI command that we may not understand fully right now. Since being correct is more important than being efficient, we should take this fix for Kepler. Once that is done, I'll open a new bug for the improvement.
(In reply to comment #5) > (In reply to comment #4) > > > Do we take this patch and create a new bug to track the missing part or do > > we modify the solution? > > I think it is too late in the cycle to start using a new MI command that we > may not understand fully right now. > > Since being correct is more important than being efficient, we should take > this fix for Kepler. Once that is done, I'll open a new bug for the > improvement. Marc, I am not familiar with the current implementation. We use var-object based registers in our product. In our case the var-object mechanism takes care of updates. I just haven't had a time to modify and submit the local patch upstream.
(In reply to comment #6) > Marc, I am not familiar with the current implementation. We use var-object > based registers in our product. In our case the var-object mechanism takes > care of updates. I just haven't had a time to modify and submit the local > patch upstream. Thanks Mikhail. I was wondering if you knew about -data-list-changed-registers: http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Data-Manipulation.html#GDB_002fMI-Data-Manipulation It seems to be a way to ask GDB what registers have changed. The current bug is that when the user changes a register, other registers can change, e.g., rax changes => eax changes. This would force us to update all registers as soon as one changes, which seems inefficient. We'll have to do that for Kepler, but I has hoping that for Luna, we could use -data-list-changed-registers to limit the scope of what needs to be updated. Since CDI uses it, I thought you may know about it.
(In reply to comment #7) > (In reply to comment #6) > > > Marc, I am not familiar with the current implementation. We use var-object > > based registers in our product. In our case the var-object mechanism takes > > care of updates. I just haven't had a time to modify and submit the local > > patch upstream. > > Thanks Mikhail. > I was wondering if you knew about -data-list-changed-registers: > http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Data- > Manipulation.html#GDB_002fMI-Data-Manipulation > > It seems to be a way to ask GDB what registers have changed. > > The current bug is that when the user changes a register, other registers > can change, e.g., rax changes => eax changes. This would force us to update > all registers as soon as one changes, which seems inefficient. We'll have > to do that for Kepler, but I has hoping that for Luna, we could use > -data-list-changed-registers to limit the scope of what needs to be updated. > Since CDI uses it, I thought you may know about it. That's how it is used in CDI but that's all I know.
I've updated Roland's so it could be committed right away. I've committed it to master from Gerrit. I'm not thrilled with the fix, but I think it is the best we can so late in the cycle. We'll improve on it for the next release. If someone has suggestions or comments, please voice them, and we'll do an update on the commit. I've opened bug 408894 to improve this solution. Thanks Roland for reporting and posting the patch!
