[binutils-gdb] Fix for spurious prompts in secondary UIs

[sergiodj+buildbot at sergiodj dot net]

*** TEST RESULTS FOR COMMIT a8836c9358a11055a08d11ecacc5d7c8f6d5e7a8 ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: a8836c9358a11055a08d11ecacc5d7c8f6d5e7a8

Fix for spurious prompts in secondary UIs

Running mi-break.exp with MI on a secondary UI reveals that MI emits
spurious prompts compared MI running as primary UI:

   -exec-continue
   ^running
   *running,thread-id="all"
   (gdb)
   =breakpoint-modified,bkpt={number="9",type="breakpoint",disp="keep",enabled="y",func="callee2",line="39",script={"set $i=0","while $i<10","print $i","set $i=$i+1","end","continue"}}
   ~"\n"
   ~"Breakpoint 9, callee2 (intarg=2, strarg=0x400730 \"A string argument.\") at ...src/gdb/testsuite/gdb.mi/basics.c:39\n"
   ~"39\t  callee3 (strarg);\n"
   *stopped,reason="breakpoint-hit",disp="keep",bkptno="9",frame={addr="0x00000000004005dd",func="callee2",...
   *running,thread-id="all"
>> (gdb)
   =breakpoint-modified,bkpt={number="9",...
   ~"\n"
   ~"Breakpoint 9, callee2 (intarg=2, strarg=0x400730 \"A string argument.\") at ...src/gdb/testsuite/gdb.mi/basics.c:39\n"
   ~"39\t  callee3 (strarg);\n"
   *stopped,reason="breakpoint-hit",disp="keep",bkptno="9",...
   *running,thread-id="all"
   ~"[Inferior 1 (process 12639) exited normally]\n"
   =thread-exited,id="1",group-id="i1"
   =thread-group-exited,id="i1",exit-code="0"
   *stopped,reason="exited-normally"
   FAIL: gdb.mi/mi-break.exp: intermediate stop and continue
   FAIL: gdb.mi/mi-break.exp: test hitting breakpoint with commands (timeout)

Note the line marked >> above.

The test sets a breakpoint that runs "continue", a foreground command.
When we get to run the "continue", we've already emitted the *stopped
event on the MI UI, and set its prompt state to PROMPT_NEEDED (this is
done from within normal_stop).  Since inferior events are always
handled with the main UI as current UI, breakpoint commands always run
with the main UI as current UI too.  This means that the "continue"
ends up always disabling the prompt on the main UI, instead of the UI
that had just been done with synchronous execution.

I think we'll want to extend this with a concept of "set of
threads/inferiors a UI/interpreter is blocked waiting on", but I'm
leaving that for a separate series.

gdb/ChangeLog:
2016-06-21  Pedro Alves  <palves@redhat.com>

	* infcmd.c (prepare_execution_command): Use
	all_uis_on_sync_execution_starting.
	* infrun.c (all_uis_on_sync_execution_starting): New function.
	* infrun.h (all_uis_on_sync_execution_starting): Declare.