Re: Towards multiprocess GDB

[Michael Eager <eager at eagercon dot com>]

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