Re: [cdt-debug-dev] Remote debugging development in CDT

["Alain Magloire" <alain@xxxxxxx>]

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

You have x variations type platforms/OS whith y number of specific compiler
options, configurations, binary formats etc ...

You can :
(a) have x * y number of resources/persons to maintain/test those platforms
  to make the user experience better.
(b) have the base plugin generic enough that third parties can use it for
  a building ground and in time things will improve.

Resources are limited.

The elected default platform by the CDT board last meeting was GNU/Linux
where default implementations are provided for all modules:
 debugger(GDB/MI), builder, indexer, etc ...
and everybody is welcome to send patches and code.

In the end,  the user experience of the CDT will depend on
the code, patches and time donated by the developers.

QNX, so far, did not shy away from this and had given code/time of
its developers.

And comes to mind, Rationale giving away the C/C++ Parser, not an easy
piece of code that they could have kept for themselves.