Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] Re: Using CDT as avr-gdb frontent for AVR tar get platforms 
   It's also important not to assume that the target that you're
   debugging is executable on the system you happen to be running on.
   I've got a situation similar to Chris' only my embedded system
   consists of a hetero mix of between 16 and 250 processors (typically
   2 flavors running Linux/MCexec/VxWorks) - each with multi-threaded
   applications running on them.  The user runs another process (runmc)
   which runs their app.  I haven't found an easy way to launch within
   CDT using another tool (line my runmc).

   Also - in order to debug multi-computer distributed applications you
   really need a process-window.  This process-window can have just the
   processes running on a compute node (for the monolothic
   applications) or be segmented along cluster/ processor/ single
   compute node.

   So - always think of how this can scale, how can it handle multiple
   independent processors of varying type and endianness, how can it
   service processes with resources that span clusters and you'll have
   the be-all and end-all of debuggers.

         --paull

Recoskie, Chris wrote:


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


_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev




--
Paul J. Leacu                   | leacu@xxxxxx
Tools Software Development      | (978) 256-0052 *1381
Mercury Computer Systems, Inc.  | http://www.mc.com

Back to the top