[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] Remote debugging development in CDT
|
At 12:54 PM 1/23/2003 +0100, you wrote:
Our company is interested in remote debugging in Eclipse/CDT
(cygwin, mips-elf-gdb). Now it is possible to remotely debug using gdb.ini
file, in which target parameters are specified.
Cdt 1.0.1 really provides building blocks rather than end solutions for
embedded development. All the things that you want are possible. I would
imagine that QNX has already built most of them as a part of proprietary
extensions and if you want to run QNX's OS it works just great.
We would like to have these features in Eclipse/CDT:
1. Additional menu in Eclipse for specifying target settings, similar to one
in Insight (Remote/Serial, Baudrate, Port; Remote/TCP, Hostname, Port).
We are working on putting these in for Xtensa right now. You are right,
there seems to be very little concept of targets built in. Keep in mind
what's possible. You can probably ask the user for a target string and pass
that to GDB. Eclipse could ask GDB what targets are supported and give a
drop down to select among them. But a slick interface to options to those
targets is going to be impossible without custom java for each target
because GDB does not have a way to give sophisticated information about the
parameters to each target.
Right now the way you support this is to write your own debugger wrapper
and launcher. A simple addition of a target string box on the CDebugTab
could probably give you basic target support.
I'd like to see what you're describing too, but only in a disinterested
fashion. Because you have to write your own debugger wrapper and launcher,
we are writing our own debugger wrapper and launcher. "Sins of the father"
you know. :)
2. Not so important but also useful would be download bar (indicates
progress of downloading code to remote target)("downloading text section:
xyz bytes". where the xyz is update
while the download progresses)
Certainly important for JTAG and serial based connections where the user is
sitting there tapping their foot. Again, if you are doing something custom,
it's very easy. IProgressMonitor is all about showing the user why they are
tapping their foot. More interesting here would be a mode that does the
download while leaving your environment live.
3. The "Registers" view does not show the reg names for the MIPS
architecture.
This is one of the things you have in insight because when building it,
you configure it for a specific architecture. How can Eclipse ask this to
gdb, I do not know.
I'd think that this would just work. Did for us. Eclipse asks GDB with the
mi command -data-list-register-names command and later gets the values with
-data-list-changed-registers. You can run gdb in mi mode by using -i mi1 on
the command line. Run your gdb in that way, issue the commands and you'll
find out why your registers are not showing up.
In the end the CDT community is going to be faced with the choice of:
improve the building blocks or improve the packaging. Do you want a
debugger that works better or is easier to get working? Much of what you
are interested in is packaging. I don't really have an opinion of which is
the right direction.
Thanks!
-Chris
