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

["Recoskie, Chris" <crecoskie@xxxxxx>]

Well, to get on my own soapbox, GDB is not the be-all and end-all of debuggers either...  CDT needs to support GDB well of course and I would never argue otherwise.  However, it needs to do this while supporting other types of debugging if it's going to truly rule the world.

If all your debugging needs are served by GDB then GDB is a great tool and I am by no means knocking it in any way.  I have used it for years and am quite fond of it.

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.  If I want to pull data out of them at high speeds without halting the target, I am even further out of luck.  GDB just isn't really built to do that.

Even using an out-of-process debugger can fall down at times if you are trying to do high-speed, near real-time debug and can't afford the extra time it takes to swap stuff in between the input and output streams of a debug process.

If anything, I would argue that CDT needs to become MORE generic under the hood.  If the default implementation of CDT sits atop GDB, then that's fantastic as there is a wide array of people who find that useful.  But there are those of us that need to do things that do not fit the stop mode, out of process, MI interface paradigm.  It is good that there is the CDI abstraction layer, but that layer in itself is pretty locked into this paradigm.

I think what I'm getting at is that, yes, GDB support has room for improvement and always will, but there is a whole set of problems right now that we currently cannot solve, which should be considered highly important to solve too.  I don't think putting our blinders on and only caring about supporting GDB to the expense of all else is the right thing to do.


___________________________________________
 
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
 
 

> -----Original Message-----
> From: cdt-debug-dev-admin@xxxxxxxxxxx [mailto:cdt-debug-dev-
> admin@xxxxxxxxxxx] On Behalf Of Øyvind Harboe
> Sent: Thursday, May 20, 2004 1:16 PM
> To: cdt-debug-dev@xxxxxxxxxxx; ThomasF@xxxxxxx
> Subject: [cdt-debug-dev] Re: Using CDT as avr-gdb frontent for AVR tar get
> platforms
> 
> >I think that the solution is to use the current extension point to
> >create a totally user customizable version of the debugger.
> 
> Please induldge me when I get up on my soapboax:
> 
> The reason why the CDT debugger is in such dire straits(i.e. that stuff
> that is trivial to do under GDB/DDD/Insight is darn hard under CDT), is
> that CDT is not delegating the problems to the right "solution
> paradigms".
> 
> Example of "solution paradigms":
> 
> - GUI
> - GDB command line
> - Plugins
> 
> * The problem of how to let the user examine local/global variables
> should be handled by "GUI". Leaving it to "GDB command line" is a
> painful.
> 
> * The problem of how to attach to the target should be handled by "GDB
> command line".
> 
> If you give this problem to "GUI and Plugins", all hell breaks loose.
> 
> No harm is done by adding buttons to CDT that simply issue issue "target
> remote foo", "run", "load", "continue", "attach 55" to GDB. This is what
> DDD/Insight does. Attaching to target is still handled by "GDB command
> line"
> 
> Be proud and embrace the GDB command line for it is powerful! :-)
> 
> Every command the user enters can take the debugger in a *completely*
> different direction.
> 
> 
> --
> Øyvind Harboe
> http://www.zylin.com
> 
> 
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev