[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Friendlier remote debugging?

Hi Alexiev,

First I'm interesting in your solution.

Why ?
We already faced this problems a few months ago, we have a very long delay between each execution step for some programs that are running on a board were a lot of threads are actives.
I started a discussion with cdt-debug-dev and gdb mailing lists, we also had
Below are some thread pointers

The main problem is that Eclipse is using the CLI command "info threads" which returns a lot of stuffs for all threads (extra information, call stack ...) that Eclipse do not need.
Eclipse is using that because some MI commands are (were) missing for getting only what he needs.

In the first time, to workaround this problem, I've hacked our gdb, adding a parameter to the "info thread" commands so that it does not return stack frame information for all threads (getting stack frames for all threads is the action that take the most time), but it's not the right thing to do since it could never been contributed. Eclipse should only use MI commands...

Long term fix
I adopt the following policy for fixing these problems:
- Develop in GDB the missing MI commands and enhance the one that can be enhanced: this aims at beeing contributed to the GNU GDB
- Modify Eclipse si that he uses these commands: I'll try this also to be accepted by the Eclipse community.

In details, Eclipse will use MI command
-thread-list-ids: this command used to return only the thread id list, its very fast, I've added to this command the current thread ID, it is not time consuming.
-thread-info for each thread he need to get information: this one will return the extra information plus the stack frame of the required thread.

I am also implementing the MI command -thread-list-all-threads that will return the list of thread ids plus their "extra information".
I will re-discuss that with GDB (and CDT) maintainers soon since I have finished the first implementation of GDB commands here.

Denis PILAT/STMicroelectronics

Alexiev, Dobrin wrote:

Hi Stuart,

I am currently implementing a solution that you may be interested in.

The problem we are facing is when we have 100s threads in our back end debugger, Eclipse connects to all of them, there is a lot of traffic and most of it is not connected to UI updates.

We decided to delay connecting to the back end thread objects until the user expands the thread in the Debug View.

This way Eclipse is talking to handful of threads at any given time. When the number of connected threads reaches a given number let’s say 10 - we dispose the least recently used connections when the target is run.

Keep in mind that we make many assumptions and that we had to modify some code in the platform debug and CDT.

Here are some of the assumptions:

- when the CPU is halted all threads are halted - it’s a stop mode debugger.

- at any given time the user is interested in only few threads.

- all other debug views show information for the current debug context - the selection in the debug view.

We haven’t completed the solution yet, but if you (or others) are interested I can submit what we’ve done so far in a separate patch. Right now I think it is specific to our case but if it helps others I can post it.

After the current release we’d like to move to DSF. I haven’t played with it yet but from the white papers looks like it can address some of these issues.




*From:* cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Stuart Fullmer
*Sent:* Monday, December 18, 2006 6:35 PM
*To:* cdt-dev@xxxxxxxxxxx
*Subject:* [cdt-dev] Friendlier remote debugging?

Hi gang, I wanted to start a dialog to get some opinions and ideas on creating a slightly friendly debugger interface for those of us doing remote debugging.


The second issue is probably much harder to solve and I don’t have a patch…yet. Background: Once a connection to the remote machine is established a lot of connection bandwidth is eaten up by the debugger requesting for and waiting on information from the server (thread names, stack info, etc.). The problem this creates is the time between hitting the step to next button and waiting for the UI to respond. For an application that has a lot of threads such as 100 for example and then to be running on a slow embedded target and then to be sending that data over a network and then not on the same local network… As you may imagine there can be quite a wait between every step. This has been reported anywhere from 2-3 minutes at times from our customers (painful!). I’ve witnessed 30s-1m on my much faster local test case.

What I would like to see is a much faster response from the UI. The UI waits for every bit of data requested from the debugger before it allows the user to continue. This makes some sense since the elements of the UI would be totally inaccurate until that information comes back. What I propose is a hybrid solution, the Prius of UI design.

The UI would be responsive as soon as the debugger notifies it that the operation has ceased. At this point the CDT would make all of its requests for program information asynchronously while at the same time all of the relevant elements of the UI would have an indicator that they have not been updated from the debugger. For example the Debug tab that displays the Threads would Say “Debug (Fetching...)”. Any thread in that debugger view would say “Thread [1] (Suspended) (Fetching...)”. This would continue on to the variable view and the registers, etc. It may be helpful to have the dots after the text changing number between 0-3 to show a pulse activity. As the data for these UI elements come in from the debugger the loading indicators would disappear. If the user hits the step key again before this data is loaded, it will be flushed and the process would start again. For our customer this could save close to 20-30mins stepping just 10 lines!

The primary goal is to make our customers user experience better. Our secondary goal is to create a solution that will work for the CDT community. I would really like to see support like this get folded back into the CDT so that it can benefit others, as the CDT has benefited us. If you have any ideas I would love to discuss them.

Thank you,



cdt-dev mailing list