This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Improving GDB for multicore and embedded system!


On Fri, 2007-03-02 at 08:54 -0500, Daniel Jacobowitz wrote:
> On Fri, Mar 02, 2007 at 10:08:55AM +0100, Denis PILAT wrote:
> > Today multicore debugging means multiple instance of gdb running at the 
> > same time. I don't know how possible it is to enhance gdb so that it can 
> > handle multiple programs running on different architecture.
> > I guess Daniel should have a good vision on that.
> No one has ever convinced me that there's a good reason to do this,
> rather than wire up things like DSF to drive multiple GDB's, if the
> cores are not all running the same architecture and program image.  If
> they are, we generally present them as threads, and that works very
> well.
> However, I have relatively little experience with non-symmetric
> multicore debugging - I have a board lab at home but it doesn't
> include any multicore targets, and we haven't done much with them at
> my job, either.  I'm always interested in learning more about new
> debugging models, or having an opportunity to do work on them.

In an earlier incarnation,  we played with getting debug working across
2 different targets ( gosh! nearly 4 years ago now) - debugging a native
x86 Linux application and the ARM Linux kernel over kgdb within the same
session. It worked ok for a prototype but then we could never get around
to doing more with it because of resource constraints and the lack of a
genuine debug use case on such a target. Getting this demo'd on a board
was a problem due to the lack of open gdb ports / JTAG interfaces for
some DSP's that were available with such SOC's then .

Another problem is the programming model on multi-cores , it varies
between platforms quite a bit - you could have a statically linked
executable with all the object files for the different cores on it built
in together - or you can have Linux apps running on something like an
ARM and a DSP application loaded separately. As you once put it in an
earlier thread -  getting the UI aspects right from the CLI as well from
MI are among the biggest challenges. 

We've had some other discussions on this list sometime in 2005.

Don't know if you have seen them -

There is always hope that sometime someday we'll be able to do something
about this . I'll watch out for that -

My 10 paise. HTH.


Ramana Radhakrishnan
GNU Tools
Celunite Inc (
Open Mobile Linux Platforms

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]