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

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
Just dumping what I have had in my mind for a long while:

I think that we're missing some concept of "set of threads the synchronous
command running on the interpreter is waiting for".

For example, if I'm debugging a bug here:

while (1)
{
   foo ();
   bar ();
}

just while other threads are running, I'll go:

 step
 next
 step
 whoops, I'm inside "bar" now
 "continue" until that breakpoint in "foo"

With that continue, I really mean:

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

So if some other thread stops meanwhile, I think that usually I'm not
interested it it right now.  If so, I would probably ideally want to ctrl-c to
get back the prompt, and then switch to that other stopped thread (which
doesn't work today; ctrl-c results in SIGINT instead of giving you the prompt,
and changing that has consequences...)

This conflicts with your suggestion.

In the "c -a" case, you're using it to mean:

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

which I think is quite reasonable.

For "run", an interpretation could be:

  "create process" + "resume process" + "wait for any thread of the created
process to stop".  Stops for other threads don't give you the prompt.

Or perhaps even better:

  "create process" + "resume process" + "wait for any thread of the created
process or any of its forked descendants to stop".

The stepping cases I think end up the same as the "continue" case above.  E.g.,
with "next", I think it'd be reasonable for a stop of any thread other than the
resumed one to not cause the "next" command to finish.  Currently what happens
is that you're given the prompt immediately, and the "next" ends up behaving
like a "next&".  That is, the next is still processing in the background.

I think something like this ends up playing better with scripts as well, as
then a canned sequence of commands involving step/next/continue/etc. applied to
a thread is not affected by what other threads trip on.

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