This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug threads/19426] in non-stop mode, gdb should sometimes select the stopping thread


https://sourceware.org/bugzilla/show_bug.cgi?id=19426

--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Also, if you do a foreground command, then when something causes a stop, and
that results in giving back the prompt to the user, I'm thinking that gdb
should select the thread that stopped.  That's why I was speaking in terms of
"giving back the prompt".

Also, I think GDB should _not_ switch the thread to the one that stopped 
all-stop mode, when the last command was a background one, for the same reasons
we don't do it in non-stop mode.

All this would merge non-stop and all-stop further.  Note that with the
direction suggested in the previous comment, the difference is that in
non-stop, with "continue", I get:

  "resume current thread" + "wait for current thread to stop".

and in all-stop, I get:

  "resume all threads" + "wait for any thread stop".

So basically the resumption command sets the interpreter to wait for any of the
threads resumed by the last synchronous command (and perhaps their children).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]