Community
Participate
Working Groups
When a register group has been expanded, it collapses automatically when returning from called functions. A demo application is attached below. Procedure: 1.start the gdb debugger, stop in main 2.expand the MAIN registers group in the registers view 3.step into the first function call 4.step into the second function call, the stack is now 3 levels deep 5.single-step-into until back in main again While returning from the called functions, the register group MAIN will collapse again, which does not happen when reducing the maximum stack depth to two. --------------------------------------------------------------------------- #include <stdio.h> int subf3(int a) { return a + 1; } int subf(int a) { return 3 + subf3(a); // when removing subf3(a), no collapse occurs } int main(void) { return subf(2); }
I observe this on any change of stack at all. Really quite annoying and renders the registers view virtually useless for tracing what's going on. At first I though it was because CDIStackFrame objects are disposed on any change of stack by CThread.computeStackFrames(), however I suppose this is done for a reason. In this case then perhaps it is the platform's Variables/Register view which is at fault. It appears to remember the current expansion / selection on some occasions (e.g. when switching between stack frames in a single suspension), but in general this is much too fragile (i.e. it will be forgotten after a suspend/resume or single step). Also what is the default expansion state when stepping into a new function? Perhaps the view is trying to be too clever? I would be happy with a static expansion state which doesn't change at all unless I tell it to.
I've made some progress into debugging this which I have recorded over at bug #155971. It seems that the platform's RegisterView (== VariablesView) goes to some length to preserve the expansion state but at some point ends up calling hasRegisterGroups() on a disposed stack frame which results in it thinking that no register groups exist and the state not getting stored. This still doesn't make it much clear where the fault is or whether a simple fix exists.
