This is the mail archive of the
mailing list for the GDB project.
Re: Improving GDB for multicore and embedded system!
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: denis dot pilat at st dot com (Denis PILAT), gdb at sourceware dot org, dominique dot toupin at ericsson dot com ("Dominique Toupin (QA/EMC)")
- Date: Mon, 5 Mar 2007 17:51:29 +0100 (CET)
- Subject: Re: Improving GDB for multicore and embedded system!
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
> 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.
We have a version of GDB that supports multi-architecture debugging
(PowerPC + SPU) on Linux for the Cell BE. This is currently not
merged upstream (and the code isn't really in a mergeable state).
[ If you're interested, a GDB source RPM including those patches is
available at http://www.bsc.es/projects/deepcomputing/linuxoncell/ ]
However, we do intend to work on common GDB infrastructure with
the goal of having mainline GDB support multi-architure debugging.
The plan here basically is:
- Complete GDB's multi-arch transition (get rid of tm.h files)
--> This will allow multiple architectures to be compiled into
a single GDB executable
- Switch from the global current_gdbarch to per-frame gdbarch
--> This should allow use of multiple architectures
concurrently within a single inferior process
None of that is really news; GDB has been moving into that
direction for a long time. It does look like with a bit of
additional effort (which we'd be willing to help put in), it
should be possible to complete those transitions in the
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE