27.1.1 Context management

27.1.1.1 Threads and Frames

In most cases when GDB accesses the target, this access is done in context of a specific thread and frame (see Frames). Often, even when accessing global data, the target requires that a thread be specified. The CLI interface maintains the selected thread and frame, and supplies them to target on each command. This is convenient, because a command line user would not want to specify that information explicitly on each command, and because user interacts with GDB via a single terminal, so no confusion is possible as to what thread and frame are the current ones.

In the case of MI, the concept of selected thread and frame is less useful. First, a frontend can easily remember this information itself. Second, a graphical frontend can have more than one window, each one used for debugging a different thread, and the frontend might want to access additional threads for internal purposes. This increases the risk that by relying on implicitly selected thread, the frontend may be operating on a wrong one. Therefore, each MI command should explicitly specify which thread and frame to operate on. To make it possible, each MI command accepts the ‘--thread’ and ‘--frame’ options, the value to each is GDB global identifier for thread and frame to operate on.

Usually, each top-level window in a frontend allows the user to select a thread and a frame, and remembers the user selection for further operations. However, in some cases GDB may suggest that the current thread or frame be changed. For example, when stopping on a breakpoint it is reasonable to switch to the thread where breakpoint is hit. For another example, if the user issues the CLI ‘thread’ or ‘frame’ commands via the frontend, it is desirable to change the frontend’s selection to the one specified by user. GDB communicates the suggestion to change current thread and frame using the ‘=thread-selected’ notification.

Note that historically, MI shares the selected thread with CLI, so frontends used the -thread-select to execute commands in the right context. However, getting this to work right is cumbersome. The simplest way is for frontend to emit -thread-select command before every command. This doubles the number of commands that need to be sent. The alternative approach is to suppress -thread-select if the selected thread in GDB is supposed to be identical to the thread the frontend wants to operate on. However, getting this optimization right can be tricky. In particular, if the frontend sends several commands to GDB, and one of the commands changes the selected thread, then the behaviour of subsequent commands will change. So, a frontend should either wait for response from such problematic commands, or explicitly add -thread-select for all subsequent commands. No frontend is known to do this exactly right, so it is suggested to just always pass the ‘--thread’ and ‘--frame’ options.

27.1.1.2 Language

The execution of several commands depends on which language is selected. By default, the current language (see show language) is used. But for commands known to be language-sensitive, it is recommended to use the ‘--language’ option. This option takes one argument, which is the name of the language to use while executing the command. For instance:

-data-evaluate-expression --language c "sizeof (void*)"
^done,value="4"
(gdb) 

The valid language names are the same names accepted by the ‘set language’ command (see Manually), excluding ‘auto’, ‘local’ or ‘unknown’.