multi-{inferior,exec}

[Stan Shebs]

Tom Tromey wrote:
> 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.
>
> [...]
>
> 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/T sets are one of the bits that didn't make it from 
multiprocess-20081120-branch to the trunk.  You can look at the branch's 
inferior.h and see the internal definition, which basically consists of 
a string that is the specification and a possibly-dynamic vector of 
inferiors computed from it.

> 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.
>   

Much of it is a matter of deciding what to iterate over, vs limiting to 
a single current inferior.  For instance, using the prefix syntax I 
originally suggested, "[4-6] print x" should print three lines, add 
three elements to value history, etc.  So one could imagine a generic 
i/t set iteration meta-command, but it's not clear that iteration is 
always the right thing to do, and maybe individual commands should 
somehow whether they are sensible for iteration.

> 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".
>   

In my global breakpoint project ( 
http://sourceware.org/ml/gdb/2010-05/msg00019.html ), I've been using a 
"process" keyword where "thread" and "task" are used now.  It doesn't 
win elegance points, but I think it corresponds better to how the user 
thinks - "OK, I'm breaking on collect_args, and oh yeah, I want to catch 
it in any process, not just the one I have now".  I don't think it would 
hurt to support a couple syntax variations, there is not going to be 
much prior expectation to accommodate.

> 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 changed TUI to use "ffocus", on the theory that there aren't many TUI 
users.  "select" isn't great because completion is ambiguous with 
"select-frame".
> 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.
>   

One advantage to prefix is that the '[' introduces the iteration desire 
succinctly.

> 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.
>   

I added a few things beyond the original spec, but it's been so long I 
don't remember what. :-)

Stan