aboutsummaryrefslogtreecommitdiff
path: root/libtool.m4
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 /libtool.m4
parent3b12939dfc2399200f243851fd55d0e392b64165 (diff)
downloadgdb-a8836c9358a11055a08d11ecacc5d7c8f6d5e7a8.zip
gdb-a8836c9358a11055a08d11ecacc5d7c8f6d5e7a8.tar.gz
gdb-a8836c9358a11055a08d11ecacc5d7c8f6d5e7a8.tar.bz2
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 'libtool.m4')
0 files changed, 0 insertions, 0 deletions