[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Suggestion for a more efficient stackframe updating

> This is a multi-part message in MIME format.
> --------------020605090804080605090206
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> When the CDT debugger becomes suspended, it updates the list of threads 
> and then updates the stackframes and variables for each thread. This can 
> be very time consuming when debugging a remote embedded target with many 
> threads. Why must the CDT debugger update the stackframes and variables 
> for _each_ thread? It would be much more efficient to just update the 
> stackframes and variables for the _current_ thread. If the user selects 
> another thread, then the stackframes and variables for that thread would 
> be updated. UI-wise, this would probably mean that only the current 
> thread is expanded while all other threads are collapsed. Selecting a 
> new current thread updates and expands that thread and collapses the 
> previously current thread.
> Of course, this new behaviour could be made as a preferences setting, 
> where the original behaviour is the default option.

For the Variables we use the gdb varobj framework.
And we were planning to change this back to just:
	-var-update *
That should take care of things.

Or maybe not 8-), the problem with this is the mix of register and
variables in the varobj certain gdb seems to crash.

For the the threads, not much we can do, gdb does not notify on
thread creation so we need to poll.

For the stackframes ... lets look at this again, do you have a PR
and test cases(MI output logs).