Decouple user selection from internal selection
I am sending this as an RFC because it's far from complete and
definitive, but I'd like to gather some comments and opinions before
going further in this direction.
The goal of this patch is to decouple the notion of the user-selected
inferior/thread/frame from GDB's internally selected
inferior/thread/frame.
Currently, for example, the inferior_ptid variable has two jobs:
- it's the user-selected thread: it's changed by the "thread" command.
Other commands (continue, backtrace, etc) apply to this thread.
- it's the internally-selected thread: it defines the thread GDB is
currently "working" on. For example, implementations of
to_xfer_partial will refer to it to know from which thread to
read/write memory.
Because of this dual usage, if we want to do some operations on a thread
other than the currently selected one, we have to save the current
inferior/thread/frame and restore them when we're done. Failing to do
so would result in an unexpected selection switch for the user.
To improve this, Pedro suggested in [1] to decouple the two concepts. This
is essentially what this patch is trying to do.
A new "user_selection" object is introduced, which contains the selected
inferior/thread/frame from the point of view of the user. Before every
command, we "apply" this selection to the core of GDB to make sure the
internal selection matches the user selection.
There is a single user selection for the whole GDB (named "global
user-selection"), but as was mentioned in the linked thread, it opens
the door to having different selections for different UIs. This means
that each UI would have its own user-selection object, which would be
applied to the core prior to executing commands from this UI.
The global user-selection object only gets modified when we really
intend to change it. It can be because of the thread / -thread-select /
up / down / frame / inferior commands, a breakpoint hit in all-stop, an
inferior exit, etc.
The problem that initially prompted this effort is that the "--thread"
flag of MI commands changes the user-selected thread under the user's
feet. My initial attempt to fix it was to restore the selection after
the MI command execution. However, some cases are hard to get right.
For example:
(thread 1 is currently selected)
-interpreter-exec --thread 2 console "thread 3"
Restoring the selected thread to thread 1 after the MI command execution
wrongfully cancels the switch to thread 3. So it's hard to determine
when we should or shouldn't restore. With the current patch, it works
naturally: the --thread flag doesn't touch the user-selected thread,
only the internal one. The "thread 3" command updates the user
selection.
Another difficulty is to send the right notifications to MI when the
user selection changes. That means to not miss any, but not send too
many either. Getting it somewhat right lead to ugly hacks (see the
command_notifies_uscc_observer function) and even then it's not perfect
(see the kfails in user-selected-context-sync.exp test). With the
proposed method, it's easy to know when the user-selection changes and
send notifications.
With this patch, there are probably a few usage of
make_cleanup_restore_current_thread that are not needed anymore, if they
are only used to restore the user selection. I kept removing them for a
later time though.
In the current state, there are a few minor regressions in the testsuite
(especially some follow-fork stuff I'm not sure how to handle), but the
vast majority of the previously passing tests still pass.
Comments are welcome!
Thanks,
Simon
[1] https://sourceware.org/ml/gdb-patches/2016-08/msg00031.html
30 files changed
