RE: [cdt-debug-dev] Re: cdt-debug-dev digest, Vol 1 #179 - 6 msgs

[Thomas Fletcher <ThomasF@xxxxxxx>]

> -----Original Message-----
> From: Øyvind Harboe [mailto:oyvind.harboe@xxxxxxxxx]
> Sent: Tuesday, December 02, 2003 8:11 AM
> To: cdt-debug-dev@xxxxxxxxxxx; alain@xxxxxxx
> Subject: [cdt-debug-dev] Re: cdt-debug-dev digest, Vol 1 #179 - 6 msgs
> 
> 
> > CDT/Debug is as good as the underlying debugger back-end.
> > If the backe-end is gdb and it fails for some reason, it is
> > unfair to blame the CDT/Debugger.
> 
> One thing I don't like about CDT is that it tries to "hide" 
> GDB and the GDB console.
> 
> Within the embedded crowd, I'm sure there is a huge crowd 
> that has a lot of Insigh exposure. CDT should tap into these 
> experiences!

Why do you think that there is more Insigh(t) exposure as opposed
to other embedded development systems? (GreenHills, Tornado, 
Lauterbach, ...)

Not that Insigh(t) isn't nice, but there are also other development
systems and debuggers which people have used.

> E.g. I want to type the GDB commands to connect the debugger to my
> target. The menus that "configure" a debug session are just 
> in the way.  At the most I want to be able to specify a GDB command 
> line(including .gdbinit script).
> 
> There is no way to launch the GDB debugger in the "idle mode"(i.e. no
> executable/symbol loaded, no target attached) that Insight launches
> itself in when insight is launched without any command line 
> parameters.

You also have to remember that GDB is only a single debugger, and just
happens to be a reference debugger being used.  The idea behind the
CDT is that other components can be plugged in, including debuggers.  

Not that I'm not advocating an ability for the _GDB component_ to have 
its own command line console, but not all debuggers will match gdb's 
functionality. Even GDB itself provides very poor synchronization of 
user driven commands and the MI layer (I'm led to believe that this 
improves with newer gdb versions) which makes it difficult to allow
all arbitrary gdb commands to be entered.  Since there is an 
expectation that GDB can hook up to the input stream and establish
a state machine of the debug target, allowing users to just type in 
random commands would actually have to be very controlled.  It also
doesn't match well with Eclipse's notion of launch configurations
which in general are pre-bound to a particular project/binary.

You could certainly work out the code which would allow a launch
configuration to start-up and then allow you a dialog to type in
your specific information ... but wouldn't you sooner put that
into an initialization (.gdbinit) file?  I think that that support
is there already today.

Perhaps I'm mis-understanding what you want to do.  It almost
sounds like you want to start up _just_ the debugger ... which
is all Insigh(t) is compared the the IDE which is what Eclipse 
is.

Thomas