This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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, 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
<misc output>
5: 45 foo() ...
6: 47 bar() ...

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!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]