See: http://sourceware.org/ml/gdb-patches/2012-02/msg00263.html and subsequent messages. It should be possible to let an event select a new thread, even in non-stop, provided that the last command invoke was a foreground command, not a background command.
I remembered why I never looked back at this. It is not clear to me we should always do that. Consider: (gdb) next * other random thread stops* [switched to $random_thread] (gdb) foofoo * next finishes later * (gdb) foofoofoofoo I think the user may want to stay focused on the "next" instead of being distracted by the other stop. Switching focus on "continue" only would be my next idea, but, I'm still not sure. The user may "break foo; continue"; and expect the foo breakpoint to hit, instead of being distracted by other threads.
My scenario was something like: debug 'make' in multi-inferior mode, run it in the foreground, lots of new inferiors are created and destroyed, then one of them crashes. Then I got output like this: [New process 2800] process 2800 is executing new program: /home/tromey/gnu/archer/Multi/crasher Program received signal SIGSEGV, Segmentation fault. 0x000000000040047f in main () at crasher.c:5 5 *x = 52; ... but I was actually debugging the original inferior, which is still running: (gdb) info inferior Num Description Executable 7 process 2800 /home/tromey/gnu/archer/Multi/crasher * 1 process 2792 /usr/bin/make I just found this very surprising. In fact the first time I didn't realize what had happened and I assumed there was a gdb bug, because I saw a crash (which visually is indistinguishable from the familiar single-inferior single-thread case) and tried to bt: (gdb) bt Target is executing.
Irrespective of foreground issues, those messages are confusing with background commands as well, for not being inferior/thread qualified. Even with breakpoint hits, you see confusing things like: (gdb) b 64 (gdb) c -a& Continuing. (gdb) Breakpoint 2, thread_function0 (arg=0x0) at threads.c:64 64 usleep (1); /* Loop increment. */ Breakpoint 2, thread_function0 (arg=0x0) at threads.c:64 64 usleep (1); /* Loop increment. */ Breakpoint 2, thread_function0 (arg=0x0) at threads.c:64 64 usleep (1); /* Loop increment. */ (that's three threads hitting a breakpoint)
Related, if/when we show the selected thread in the prompt (e.g., "thread N>", then with: thread 1> c (or c& or whatever) Thread 2 [foo bar] received signal SIGSEGV, Segmentation fault. 0x000000000040047f in main () at crasher.c:5 5 *x = 52; thread 1> the question of whether to switch the thread on event is no longer one about confusion/surprise, but about convenience (and that depends on use case).
FWIW I ran into this again today doing multi-inferior debugging. The current behavior is quite confusing, given that the mode I'm using is "set a catchpoint and then continue the entire tree of processes". The current behavior would be less confusing if gdb printed a warning: "hey, even though this breakpoint hit in inferor N, you're still looking at thread M."