This is the mail archive of the
gdb@sourceware.org
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
> 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.
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
not-too-distant future.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com