multi-{inferior,exec}

[Tom Tromey <tromey@redhat.com>]

I've been looking at multi-inferior/multi-exec the last few days.  I
want to polish a few edges and make it work nicely on Linux.  I thought
I'd post about what I think I am going to implement.

First, the original spec:

    http://sourceware.org/ml/gdb/2008-08/msg00169.html

Also relevant:

    http://sourceware.org/gdb/wiki/MultiProcess


One concrete thing I plan to do is make objfiles not be relocated,
basically following the idea here:

    http://sourceware.org/ml/gdb-patches/2009-06/msg00668.html

This is mostly plumbing, but important for efficiency.


I think the next missing bit is support for I/T sets.  E.g., I wanted to
try to debug g++ but put a breakpoint in its cc1plus subprocess.  You
can do this today, but only clumsily: either by using add-inferior to
load the symbols for cc1plus, or by using "catch exec" and setting the
breakpoint at exec time.  I/T sets would let users set this sort of
breakpoint more easily.

I am not sure what is required to integrate I/T sets into inferior
control (something mentioned on the wiki page).  If anyone (Pedro?
Stan?) has state to share, I'm happy to hear it.

I think we can add an I/T set specifier before the linespec argument to
"break".  (I couldn't think of other commands that use linespecs that
would need this...)  E.g., in the g++ scenario, this would set a
breakpoint that would be resolved in libcpp:

    (gdb) break [*] collect_args

"[*]" is the I/T set representing "all current or future inferiors".

If no I/T set is specified, it would default to the current inferior.

The original spec had a "focus" command... but that is already used by
the TUI.  How did that get resolved?  It seems to me that we could just
use "select" instead.

I was thinking it would be nice to extend "thread apply" to take an I/T
set argument.  Maybe "inferior apply" is a nicer way to spell it.

I think maybe the I/T set syntax could be expanded or changed a little.
I'm at least thinking of "." as a synonym for "current inferior", and
being able to differentiate named sets and executables.


There are more tasks beyond those, but I think those will hold me for a
while.  The remaining big things I am aware of (thanks Pedro) are:

* Model follow-fork|vfork|exec in remote protocol + remote.c + gdbserver

* gdbserver needs work for multi-inferior + multi-arch
  Maybe we need a target description per inferior here.

Tom