[cdt-debug-dev] Re: CDT 1.2.0.50 success story for arm JTAG eCos develop

["Alain Magloire" <alain@xxxxxxx>]

> 
> > > I've now upgraded to CDT 1.2.0.50 and it has resolved the
> > > issues with attach source and CygWin paths and a handfull
> > > of other quirks (terminate now terminates the arm-elf-gdb.exe
> > > process) :-)
> > >
> >
> > Very cool!
> >
> > So are getting close to surpass GNU insight ?
> > Since it seems to be your benchmark ;-)
> 
> I can use Eclipse CDT about 30% of the time when I'm debugging
> eCos and about 70% when I'm debugging my own app and eCos is behaving.
> These figures have been steadily improving so far.
> 
> The areas where Insight scores over CDT(in no particular order) currently:
> 
> - Command line invocation on an arbitary executable compiled outside
> Eclipse/CDT.

Something for the future, now eclipse has the concept of IResource where things
must live in the workspace.  Things may be more easier with Eclipse-3.0.

> - There is no unchanging gdbinit when I debug using a JTAG debugger. Insight
> lets me type in a "gdbinit" interactively. CDT has no concept of launching
> the
> debugger without being attached to a target and allowing me to type the GDB
> commands. The target is a bit flaky as well. If you examine my the gdbinit
> that

insight is gdb 8-), i.e. insight is link with libgdb.a and have access
to all gdb commands.  The bad thing is that because of it they are closely
tied to any given version of gdb etc ...

I had a quick thread with Jim I. from Apple, he implemented something
call
"-interpreter-exec console-quoted" 

With this it will be possible do much more powerfull things in term of console
prompt an synchronisation with the IDE.  ... 'til then ...
However the patch is available from apple but just not in the mailine FSF GDB.

> I attached, there where some "sleep" commands to try to work around the
> that
> the "monitor" commands can be asynchronous.

> - CDT does not list all source files for the executable such that I can set
> a
> breakpoint in an arbitary file before debugging starts, i.e. frequently I
> want
> to set a breakpoint.
> 

Noted, a good point.
We could do this in a different ways:
(1) via eclipse and the binary parser, it's another concept and we would
need to enhance the CDT/ElfParser for STABS/DWARF and the Core Model.
(2) by providing a little dialog ....

Of course I prefer (1) 8-)

> One day when CDT works as a standalone debugger, it would be cool to compile
> it
> with GCJ. You would then have a standalone C++ debugger that does not
> require a
> JRE. This should be psychologically important for hardended C/C++
> programmers ;-

It can be done now ... in a bizarre kind a way.
But there is more to it,  there is no way now to set a "C/GDB" breakpoint
to the JavaEditor etc ..  We would probably need some C --> Java layer et ...

> > > - I use the "CygWin GDB debugger"
> > > - The bdigdbinit attached  (for a BDI2000 JTAG debugger
> > > and EB40a evaluation board)
> > >
> > > The only thing that stops CDT from working out of the box
> > > is that I need to modify plugin.xml(patch attached).
> 
> The "CygWin GDB debugger" works fine as it is! All I have to do is to remove
> the safety guards that stops me from accessing arm elf executables...
> 
> Every time I update to the daily build I have to manually do this
> modification.
> I support a couple of hardware engineers who use CDT for firmware
> development,
> and this is just another little thing to alienate them.
> 
> Please?

The idea is to provide a third party plugin to "enhance" the
the default ones.

> 
> > Ha yes ... we've discuss this before. Like for the PALM OS and others
> > it should be in another third party plugin that will contribute to the
> > debugger.
> 
> How about bundling a "manual" plugin?
> 
> Some thoughts on this:
> 
> - Remove any assumptions about CPU
> - Configurable command line invocation of arm-elf-gdb. Basically
> - CDT should assume nothing about the state of the debugger(i.e. GDB could
> be
> in the suspended, detached, etc.) when a debug session is launched. The
> developer would either write a gdbinit or manually type in the commands to
> attach to the target.
> - It should also support command line invocation a-la Insight. Possibly with
> a
> dummy empty project.
> 

Food for thoughts.

> > But I think your point was, you do not even want to do Java code however
> > minimal.
> > Not sure how to balance the requests without bloating the CDT debugger
> with
> > lots
> > of slightly different GDB based debuggers.
> 
> This is not true. I wrote a patch to work around the "attach source"
> w/CygWin
> problem that has now been fixed such that I could debug eCos from Eclipse.
> My plugin.xml patch was dismissed. :-)
> 
> Once I get a bit more up to speed on CDT >= 1.2.0.50, I might attempt one or
> two tweaks.
> 
> Insight(your competition ;-) works out of the box.
> 

True, in term of debugging 8-).