Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT and GDB over serial performance

I’d bet it’s the massive number of threads. It’s not kind to make our users go to the preferences to solve that problem, though. We should be more measured in the calls we make and make sure we’re doing things in an asynchronous fashion (which is why we did DSF), but also prioritize what we show so something shows up early.


From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Monday, August 31, 2015 at 2:01 PM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] CDT and GDB over serial performance

First I would confirm that the performance slowdown is triggered by CDT and not by GDB itself.  Although your command-line GDB is fast, it may be that some of the settings used by CDT make it slower on your target.  You can look at CDT's 'gdb traces' output to see what CDT is requesting of GDB and if that is the cause of the slowdown.  You can also try to run the same settings used by CDT in a command-line GDB so see if you get the same slow down.  You can do that very easily by parsing the 'gdb traces' that setup GDB and copy-pasting the result in the command-line GDB.  You can parse nicely using this:

If the problem is not in the settings used by CDT but in the amount of info requested, then you can reduce the amount of info requested by hiding views or/and data.  DSF only sends GDB requests for data that is visible to the user, so if you are not interested in variables, or if they slow you down, you could simply hide that view (you could use the expressions view to select which variable to show).  Same goes for registers, modules, etc.

You could also reduce the amount of stack frames that CDT shows. 
Preferences->Run/Debug->View performance
then change "Limit the number of strack frames to" from 10 to maybe 2 or 3.
You can also only display threads that are stopped, although I don't know if that will reduce communication with GDB:
Preferences->C/C++->Debug->GDB->Show only suspended threads in debug view.

I hope this helps.

From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Oberhuber, Martin [Martin.Oberhuber@xxxxxxxxxxxxx]
Sent: August 31, 2015 1:43 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] CDT and GDB over serial performance

Hi CDT/GDB experts,


I’ve been trying to use CDT for some Linux Kernel debugging (using kgdboc, which goes over a 115.200 baud serial line). I’ve not been using the “GDB Hardware Debugging” launch but the standard DSF-GDB Manual Launcher since my remote serial line is available through a Telnet portserver.


It turns out that CDT is unbearably slow in this scenario: Initial connect in the range of 2 minutes; operations like simple “suspend on breakpoint” in the range of 15 seconds. I suspect the reason is, that 200 Kernel Threads are detected and CDT tries to do much target introspection … so there’s a lot of traffic making the UX extremely slow.


Using GDB commandline in this scenario works quite nicely, commandline GDB requests one item of information at a time only. I think ideally, CDT could add a lot of value to this (source display, variable hovers, …) so I am wondering if there’s any switches to tune performance, ie turn off target introspection that is unnecessary ?





Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6


Back to the top