[
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
http://dev.eclipse.org/mhonarc/lists/cdt-debug-dev/msg01515.html
http://sources.redhat.com/ml/gdb/2006-09/msg00178.html
http://sources.redhat.com/ml/gdb/2006-09/msg00096.html
Problem:
-------
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.
Workaround
----------
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.
Regards
Dobrin
------------------------------------------------------------------------
*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,
-Stu
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
