[cdt-debug-dev] Re: cdt-debug-dev digest, Vol 1 #160 - 3 msgs

[Ø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