This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Towards multiprocess GDB
- From: Michael Eager <eager at eagercon dot com>
- To: Stan Shebs <stanshebs at earthlink dot net>
- Cc: gdb at sourceware dot org
- Date: Mon, 21 Jul 2008 09:06:36 -0700
- Subject: Re: Towards multiprocess GDB
- References: <4880FFA8.3080600@earthlink.net>
Stan Shebs wrote:
CodeSourcery has a project to add "multiprocess" capability to GDB,
and with this message I'd like to kick off some discussion of what
that means and how to make it happen.
To put it simply, the goal of the project is to make this command work
in some useful way:
gdb prog1 prog2 pid2 prog3 prog4
As the command suggests, we're talking about multiple programs or
executables being controlled by a single GDB, in contrast to a single
program with multiple processes or forks, a la Michael's machinery for
Linux forks. So although we often use the term "multiprocess", it's
perhaps more precise to call it "multiprogram" or "multiexec" GDB.
I think that this is a subset of what is actually needed. A good
starting point, but it doesn't address present and future architectures.
I would like to see GDB become a multi-process, multi-target, multi-
architecture debugger. There are many multi-processor systems, where
several processing units make up the target. One example is the Cell:
a PowerPC processor connected to multiple special-purpose processors.
There are many RISC-DSP processors; there are efforts to re-purpose
Nvidia's massively parallel GPUs to more conventional programming;
and the future of processor design is multicore, not all of will be
the same architecture or connected symmetrically. An SMP architecture
running a single Linux OS is a subset.
The target abstraction to support this needs to permit multiple
threads on multiple targets, with different architectures, different
executables, and different communication protocols.
Clearly, if this were the target abstraction, supporting multiple
processes running on the same processor under a single OS would
be easy. A design which only focuses on this subset will not be
easy to extend to multiple dissimilar execution environments.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077