Previous: Asynchronous and non-stop modes, Up: GDB/MI General Design

#### 27.1.3 Thread groups

gdb may be used to debug several processes at the same time. On some platfroms, gdb may support debugging of several hardware systems, each one having several cores with several different processes running on each core. This section describes the MI mechanism to support such debugging scenarios.

The key observation is that regardless of the structure of the target, MI can have a global list of threads, because most commands that accept the ``--thread`' option do not need to know what process that thread belongs to. Therefore, it is not necessary to introduce neither additional ``--process`' option, nor an notion of the current process in the MI interface. The only strictly new feature that is required is the ability to find how the threads are grouped into processes.

To allow the user to discover such grouping, and to support arbitrary hierarchy of machines/cores/processes, MI introduces the concept of a thread group. Thread group is a collection of threads and other thread groups. A thread group always has a string identifier, a type, and may have additional attributes specific to the type. A new command, `-list-thread-groups`, returns the list of top-level thread groups, which correspond to processes that gdb is debugging at the moment. By passing an identifier of a thread group to the `-list-thread-groups` command, it is possible to obtain the members of specific thread group.

To allow the user to easily discover processes, and other objects, he wishes to debug, a concept of available thread group is introduced. Available thread group is an thread group that gdb is not debugging, but that can be attached to, using the `-target-attach` command. The list of available top-level thread groups can be obtained using ``-list-thread-groups --available`'. In general, the content of a thread group may be only retrieved only after attaching to that thread group.