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 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 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’ command via the frontend, it is desirable to change the frontend's selected thread to the one specified by user. gdb communicates the suggestion to change current thread using the ‘=thread-selected’ notification. No such notification is available for the selected frame at the moment.
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.
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’.