This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
multi-{inferior,exec}
- From: Tom Tromey <tromey at redhat dot com>
- To: GDB Development <gdb at sourceware dot org>
- Date: Fri, 03 Sep 2010 16:40:53 -0600
- Subject: multi-{inferior,exec}
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