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

[Øyvind Harboe <oyvind.harboe@xxxxxxxxx>]

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

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 ;-
)

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

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

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

Øyvind