Toward multicore GDB - Set theory

[Stan Shebs <stanshebs at earthlink dot net>]

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 
(http://www.roguewave.com/support/product-documentation/totalview-family.aspx#totalview 
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
<misc output>
5: 45 foo() ...
6: 47 bar() ...
...
(gdb)

Similarly, the single-thread option for breakpoints will be generalized 
to sets.

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

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!

Stan
stan@codesourcery.com