[PATCH] gdb: Restore previously selected thread when switching inferior

[Pedro Alves]

On 3/27/20 1:30 PM, Andrew Burgess wrote:
> This commit changes how GDB behaves when switching between
> multi-threaded inferiors.
> 
> Previously when switching GDB would select "any" thread from the
> inferior being switched to.  In practice this usually means the thread
> with the lowest thread number.
> 
> After this commit GDB remembers which thread the user had selected
> within the inferior and tries to reselect that thread when switching
> back to an inferior.  The assumption is that the selected thread is
> the one that the user is most interested in, and so switching back to
> that makes more sense than selecting some other thread.
> 
> If the previously selected thread is no longer available, for example,
> if the thread has exited, then GDB will fall back on the old
> behaviour.
> 
> I did consider making this behaviour switchable, but the new behaviour
> seems (to me) obviously better, so I haven't added a switch for it.
> However, if people feel the old behaviour is worth preserving then I'm
> happy to add a switch.
> 
> The other thing I considered, but didn't do is to add a warning when
> switching inferiors if the previously selected thread is no longer
> available.  My reasoning here is that GDB should already have informed
> the user that the thread has exited, and there is already a message
> indicating which thread has been switched too, so adding an extra
> warning felt like unneeded clutter, but again, if people feel strongly
> that there should be a warning, I'm happy to add one.
> 
> One test needed to be updated after this change, and there's a new
> test that covers this behaviour in more depth.

Frankly, I'm not really sure I like this.  It seems like a can of worms to
me...  It's going to cause us to have to decide whether it's a good idea to
save/restore all kinds of state in the objects hierarchy.  E.g., if this is
reasonable, then it would also be reasonable to restore the selected
Ada task.  And frames.  And maybe the selected source file and line for
list.  Once we gain support for fibers, coroutines, etc. we'll
then need to apply the same logic.  Etc.  And then maybe we'll need
some way to query the selected thread of a given inferior.  Etc.

The current rule is quite simple.  If you select a object then its container
is implicitly selected.  So if you select a thread, you implicitly select
its inferior, and implicitly select its target.  And the first/initial container
object is selected.  It seems very natural to me that "inferior 2" ends up
selecting the initial thread of inferior 2.  I.e., normally, thread 2.1.

Thanks,
Pedro Alves