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

[Oyvind Harboe <oyvind.harboe@xxxxxxxxx>]

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

Paraphrase from Space Balls: "I hate a fair fight." :-)

>With this it will be possible do much more powerfull things in term of
console
>prompt an synchronisation with the IDE.  ... 'til then ...

For the record:

My e-mail was titled "success story". CDT has come a long way since
1.2.0.13.

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

Would it be possible for Eclipse to support being started in the detached,
non-running state?

That way I could set a break point from the GDB command line console
manually
before execution starts.

>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 was mainly thinking about CDT as a pure C++ development environment, so
in this case the JavaEditor/Perspective would be removed from the build.
(Or at least made invisible if CDT somehow relies on those classes).

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

But, but, but... CDT already works! There is no need for a plugin for
embedded work. Just remove one safety-strap(or is there cpu="all" for
the plugin.xml?)

Embedded and hardware developers are *not* spoilt with smooth, bug-free
IDEs(that I know). I haven't seen a commerical one I liked better than
CDT or Emacs+Insight.

Oyvind