This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Non-stop multi-threaded debugging
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: nathan at codesourcery dot com (Nathan Sidwell)
- Cc: gdb at sourceware dot org, jimb at codesourcery dot com (Jim Blandy)
- Date: Tue, 27 Nov 2007 17:42:47 +0100 (CET)
- Subject: Re: Non-stop multi-threaded debugging
Nathan Sidwell wrote:
> A client of CodeSourcery's has contracted with us to implement a
> number of new features in GDB, some of which have been on the
> frequently requested list for quite some time:
Thanks, these are indeed very interesting and useful features.
> - We're to implement a limited form of multi-process debugging.
>
> Full multi-process debugging would entail changes to
> 1) process management code,
> 2) target interfaces, and
> 3) symbol tables.
> Our client would very much like for this work to be incorporated into
> the public GDB sources (although they understand that the decision is
> in the public project's hands), so we'll be posting our design
> thoughts for general discussion. In particular, I believe the
> multi-process work may overlap with some of the work IBM has done to
> support the Cell processor; we'd very much like to work with IBM to
> ensure that the final model is appropriate for both our client and for
> Cell developers.
It looks like the points 1) and 2) you are planning to address
actually do *not* overlap with the work we've been doing on the
Cell combined debugger. The Cell programming model our debugger
supports is bascially a regular multi-threaded model, except that
some threads may execute either PowerPC or SPU architecture code
at any time. Multi-process support is not required.
[ However, of course multi-process support would be a nice *extension*
to the Cell combined debugger, allowing to debug multiple processes,
each of which follows the normal multi-threaded Cell model. ]
Point 3) above would be relevant to the Cell combined debugger as well.
You do not address this point in more detail in your document, but I
assume this would imply introducing the notion of "address spaces" and
associating symbol tables to a particular address space. Something
similar is already needed for the Cell combined debugger, as we have
multiple address spaces even within a single process. I'm definitely
interested in working on adding this support to mainline GDB -- if
that then also helps the multi-process work, that's an additional
benefit.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com