Community
Participate
Working Groups
There are a few views that require a suspended debug context before they may communicate with the remote target to gather the information that they require. This is a holdover from the early days of CDT, when gdb was synchronous and all-stop. In most instances this is because the underlying services used to populate these views set context availability with CommandCache#setContextAvailability, which is in turn used by CommandCache#execute. If a context is not available CommandCache#execute will fail. A short list of views that should function regardless of the current state: Variables Expressions Disassembly
(In reply to Stephen Flynn from comment #0) > A short list of views that should function regardless of the current state: > > Variables > Expressions How would we display variables/expressions if the thread in question is running and those variables/expressions are changing? > Disassembly That seems ok.
(In reply to Marc Khouzam from comment #1) > (In reply to Stephen Flynn from comment #0) > > > A short list of views that should function regardless of the current state: > > > > Variables > > Expressions > > How would we display variables/expressions if the thread in question is > running and those variables/expressions are changing? I would recommend a scheme similar to the Trace Control view, where there are 'Refresh' and 'Refresh view automatically' commands. I would further recommend there be a user settable preference for the update interval. A context change to a suspended thread would force an update. A way to limit the impact view-wise would be to make changes solely to the Expressions view, but this would mean the user would lose the benefit of the 'Add Global Variables' command in the Variables view. Although this could be ported into the Expressions view. > > > Disassembly > > That seems ok.
(In reply to Stephen Flynn from comment #2) > (In reply to Marc Khouzam from comment #1) > > (In reply to Stephen Flynn from comment #0) > > > > > A short list of views that should function regardless of the current state: > > > > > > Variables > > > Expressions > > > > How would we display variables/expressions if the thread in question is > > running and those variables/expressions are changing? > > I would recommend a scheme similar to the Trace Control view, where there > are 'Refresh' and 'Refresh view automatically' commands. I would further > recommend there be a user settable preference for the update interval. Sorry for not replying sooner. So what you are suggesting is to not delete the displayed values automatically when a thread resumes?
(In reply to Marc Khouzam from comment #3) > (In reply to Stephen Flynn from comment #2) > > (In reply to Marc Khouzam from comment #1) > > > (In reply to Stephen Flynn from comment #0) > > > > > > > A short list of views that should function regardless of the current state: > > > > > > > > Variables > > > > Expressions > > > > > > How would we display variables/expressions if the thread in question is > > > running and those variables/expressions are changing? > > > > I would recommend a scheme similar to the Trace Control view, where there > > are 'Refresh' and 'Refresh view automatically' commands. I would further > > recommend there be a user settable preference for the update interval. > > Sorry for not replying sooner. > So what you are suggesting is to not delete the displayed values > automatically when a thread resumes? The availability of a local value would be context dependent. Moving from a suspended context to a live thread would mean values for local variables would not be available, so I do not think displaying its last value would be informative. But in the case of of global variables, keeping the last value makes more sense, and having a refresh button would allow updating the value in a context independent way.
