This is the mail archive of the
mailing list for the GDB project.
Toward multicore GDB - Set theory
- From: Stan Shebs <stanshebs at earthlink dot net>
- To: gdb at sourceware dot org
- Date: Tue, 01 Nov 2011 17:03:51 -0700
- Subject: Toward multicore GDB - Set theory
In a program with hundreds or even thousands of threads, the user cannot
be effective with the two options that GDB currently provides - work
with one thread, or all of them at once.
This was anticipated some years ago in the discussions of the HPD forum
that Michael Snyder and I participated in. The resulting spec
introduced the concept of the process/thread set (see
http://sourceware.org/frysk/documentation/hpd.html), which was
implemented in the TotalView debugger
for the user manual). We extend sets to include cores, about which more
in a moment.
The basic idea is simple; a p/t set is just a set of processes and
threads. We introduce a notation that allows us to construct sets,
where <process>.<thread> refers to a particular thread of a process, and
the two components can be elided, wildcarded, etc. So we would have
things like [4523,16493] for a set of two processes, [4523.workerbee]
for a particular named thread, [4523.1-7,*.8-15] for eight threads of
one process plus all threads numbered 8 to 15 from any other process
under our control, and so forth.
We then use set notation interesting with commands:
(gdb) [.7-80] print mytlsglob
$45 = [.8,16,32,64] 0xbadbad ; [.*] 0xfeedface
shows most threads with the same value for a variable, and a handful of
threads with a different value.
Similarly, you could do selective stepping, in this case to step just
four threads of a process:
(gdb) [.5-8] step
5: 45 foo() ...
6: 47 bar() ...
Similarly, the single-thread option for breakpoints will be generalized
Users will expect to be able to do all the usual set operations (union,
intersection, negation), and to apply names to sets. There needs to be
a "focus" command that sets the default set of interest, applied to
It should also be possible to define sets with predicates - [1245.*] can
be thought of as having a predicate that is true for any thread of
process 1245. Additional predicates could be things like [1245.*future]
for any thread not existing at the time the set is defined, or
[1245.*suspended] for any thread that is not running at the moment.
Well, you say, all very interesting, but what does this have to with
cores? As a thread-like hardware resource, what really goes on with
cores is assignment of processes and threads to cores. So our idea is
to add it as a sort of predicate-like annotation to p/t sets, yielding
set descriptions like [4523.*@45], which designates all the threads of
process 4523 that are currently assigned to core 45.
The astute reader will notice many holes. In particular, I am not
giving a formal definition of set syntax and how it fits into the CLI,
because I want us to develop some consensus on what would work best.
Key decisions to be made are:
1) square brackets? curly brackets? nothing at all?
2) prefix? postfix? both?
3) build in extensibility? or leave to Python somehow?
4) is there a better term than ptc set?
Set operations applied to execution control present some implementation
challenges, and if you've been following Pedro's recent work, one of the
goals is to remove the single-threaded all-or-nothing assumptions that
have been in GDB's native support for a long time. After that we expect
to post a first version of ptc set support, and then the fun really begins!