RE: [cdt-debug-dev] Re: Using CDT as avr-gdb frontent for AVR tar

[Chris Songer <songer@xxxxxxxxxxxxx>]

At 12:43 PM 5/20/2004 -0500, Recoskie, Chris wrote:

> However, there are plenty of problem spaces (especially the embedded 
> space) where GDB and even just the generic paradigm of stop-mode, single 
> processor debug fall short.  If I've got 6 processors all on the same JTAG 
> scan chain that I need to debug simultaneously, I can't easily use GDB to 
> do that.

It's the 6 processors more than the scan chain, but your point is totally 
valid. :)

We deal with that all the time. Because we are an configurable processor IP 
company, rather than a chip company we have almost a worst case scenario. 
We have to support arbitrary core JTAG topology with differently configured 
cores on the chain. We also provide a high level modeling library for 
customers to create their SoC in C so that they can test different 
architectures in advance of silicon and without getting the 10 cycles per 
second that they'd get in an RTL simulation. That gives us a simulation 
target in addition to a hardware target.

For the most part "CDT as a library" makes this very easy. With only the 
additon of a new launcher or two, we can connect N debuggers to a system 
either in simulation or on hardware and do it with one click. The CDT 
debugger UI is then much nicer and easier to use than N command line GDBs.

Anyway, CDT-debug should not be eclipse hosted DDD in my opinion. I'd 
rather see it be eclipse hosted DevStudio debug.

That said, there is a bug on our internal logs titled: "Debugger console 
should be removed or made into full-featured xt-gdb console". The engineer 
who logged it is probably right.

Thanks!
-Chris