Skip to main content

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

I filed this enhancement suggestion as PR 89809 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=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 is expensive.

Regards,
Stefan

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>
To: <cdt-dev@xxxxxxxxxxx>
Sent: Wednesday, March 30, 2005 4:45 PM
Subject: 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).


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

begin:vcard
fn:Stefan Bylund
n:Bylund;Stefan
org:Enea Embedded Technology AB
adr;quoted-printable;quoted-printable:;;Nytorpsv=C3=A4gen 5B, Box 232;T=C3=A4by;;183 23;Sweden
email;internet:steby@xxxxxxx
title:Software Engineer
tel;work:+46 8 50714000
tel;cell:+46 709 714325
url:http://www.ose.com
version:2.1
end:vcard


Back to the top