| [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 |