summaryrefslogtreecommitdiff
path: root/gdb/infrun.h
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2016-06-21 01:11:52 +0100
committerPedro Alves <palves@redhat.com>2016-06-21 01:11:52 +0100
commita8836c9358a11055a08d11ecacc5d7c8f6d5e7a8 (patch)
tree054740b78025d5ae7748f5168ccee7bb3a9b3ded /gdb/infrun.h
parent3b12939dfc2399200f243851fd55d0e392b64165 (diff)
downloadbinutils-gdb-a8836c9358a11055a08d11ecacc5d7c8f6d5e7a8.tar.gz
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.
Diffstat (limited to 'gdb/infrun.h')
-rw-r--r--gdb/infrun.h5
1 files changed, 5 insertions, 0 deletions
diff --git a/gdb/infrun.h b/gdb/infrun.h
index 01eff9a1dbd..39be375fbe9 100644
--- a/gdb/infrun.h
+++ b/gdb/infrun.h
@@ -238,4 +238,9 @@ extern void maybe_remove_breakpoints (void);
ready for input). */
extern void all_uis_check_sync_execution_done (void);
+/* If a UI was in sync execution mode, and hasn't displayed the prompt
+ yet, re-disable its prompt (a synchronous execution command was
+ started or re-started). */
+extern void all_uis_on_sync_execution_starting (void);
+
#endif /* INFRUN_H */