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 first issue is really simple. The current MI spawner does not pass
environment variables for the debugger process. When I end up using my
mips2-gdb.exe instead of the gdb that comes with cygwin, I get errors because
the required dlls can not be located. The setup requires paths to be passed to
the launch process. I’ve found two bugs associated with this: Bug 108037
and Bug 149044. They both have my proposed patch, but 108037 has the newest
version of the same patch and should be compatible with the most recent
release. The patch uses an attribute to pass the environment to the debug launcher
and then the env. is propagated down the line through function parameters.
---------
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