[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] Suggestion for a more efficient stackframe updating
- From: Stefan Bylund <steby@xxxxxxx>
- Date: Thu, 31 Mar 2005 14:02:07 +0200
- Delivered-to: email@example.com
- User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)
I filed this enhancement suggestion as PR 89809
I agree that the list of threads must be updated after each suspension;
my point was that the stackframes and variables only need to be updated
for the current thread, not for all the threads. I think this
improvement could be a major performance booster for debugging programs
with many threads, especially for targets where computing the backtrace
Mikhail Khodjaiants wrote:
The threads and shared libraries should be updated automatically, not
much we can do.
But we should consider to use update requests from the UI for stack
frames, variables, etc.
----- Original Message ----- From: "Alain Magloire" <alain@xxxxxxx>
Sent: Wednesday, March 30, 2005 4:45 PM
Subject: Re: [cdt-dev] Suggestion for a more efficient stackframe
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii; format=flowed
When the CDT debugger becomes suspended, it updates the list of threads
and then updates the stackframes and variables for each thread. This
be very time consuming when debugging a remote embedded target with
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
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:
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).
cdt-dev mailing list
cdt-dev mailing list
org:Enea Embedded Technology AB
adr;quoted-printable;quoted-printable:;;Nytorpsv=C3=A4gen 5B, Box 232;T=C3=A4by;;183 23;Sweden
tel;work:+46 8 50714000
tel;cell:+46 709 714325