Fix for spurious prompts in secondary UIs
authorPedro Alves <palves@redhat.com>
Tue, 21 Jun 2016 00:11:52 +0000 (01:11 +0100)
committerPedro Alves <palves@redhat.com>
Tue, 21 Jun 2016 00:11:52 +0000 (01:11 +0100)
commita8836c9358a11055a08d11ecacc5d7c8f6d5e7a8
tree054740b78025d5ae7748f5168ccee7bb3a9b3ded
parent3b12939dfc2399200f243851fd55d0e392b64165
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.
gdb/ChangeLog
gdb/infcmd.c
gdb/infrun.c
gdb/infrun.h