Re: Inadvertently run inferior threads

[Pedro Alves <palves at redhat dot com>]

On 06/23/2015 05:07 AM, Doug Evans wrote:

> Maybe we could give up on trying to cover up the stopped/running state
> of the thread and just let info threads report something closer to
> what's actually going on?
> An asterisk or some such accompanying the output of threads in
> intermediate states may be a sufficient clue to the the user.

I strongly disagree.

Plus, frontends also don't want to be flooded with useless
*running -> *stopped -> *running transitions.

Hiding internal stops isn't the complicated part.  It's the opposite
that is causing problems.  That is, the hiding that threads run at all
when doing an infcall:

 (gdb)
 p malloc (0)
 &"p malloc (0)\n"
 ~"$1 = (void *) 0x602010\n"
 ^done
 (gdb)

Note no *running/*stopped above.

The next question should be: if you do "print sleep (10000)", then
since the thread / threads was/were never marked running, does that mean that
the user/frontend can end up issuing another execution command
that corrupts the ongoing infcall?  The answer is no, but just because
infcalls are always synchronous, so there's no way to issue any command
while an infcall is ongoing anyway.  More about it here:

 https://sourceware.org/ml/gdb-patches/2014-05/msg00273.html

But fixing this bug may require removing the infcall-specific
(pretend-it-doesnt-run) suppressions, resulting in something like:

 (gdb)
 p malloc (0)
 *running,thread-id="all"
 &"p malloc (0)\n"
 ~"$1 = (void *) 0x602010\n"
 *stopped,frame={addr="0x000000000040071c",func="main",args=[{name="argc",value="1"}, (...) ,thread-id="1",stopped-threads="all",core="3" ^done
 (gdb)

I'm playing with tests and potential solutions.

Thanks,
Pedro Alves