When running gdb.mi/mi-solib.exp with displaced stepping turned on (native gdb), I get one fail, FAIL: gdb.mi/mi-solib.exp: check for solib event (timeout) gdb.log: PASS: gdb.mi/mi-solib.exp: set stop-on-solib-events run ^M &"run \n"^M ~"Starting program: /home/yao/SourceCode/gnu/gdb/git.new/build-x86/gdb/testsuite/gdb.mi/solib-main \n"^M =thread-group-started,id="i1",pid="2998"^M =thread-created,id="1",group-id="i1"^M ^running^M *running,thread-id="all"^M =library-loaded,id="/lib/ld-linux.so.2",target-name="/lib/ld-linux.so.2",host-name="/lib/ld-linux.so.2",symbols-loaded="0",thread-group="i1"^M (gdb) ^M *stopped,reason="solib-event",thread-id="1",stopped-threads=["1"],core="3"^M mi_expect_stop: expecting: \*stopped,reason="solib-event",.*frame={addr="0x[0-9A-Fa-f]+",func=".*",args=\[.*\],(?:file="[^ ]*.*",fullname="(/[^\n]*/|\\\\[^\\]+\\[^\n]+\\|\\[^\\][^\n]*\\|[a-zA-Z]:[^\n]*\\).*",line=".*"|from=".*")}.*,thread-id="[0-9]+",stopped-threads=[^ ]*^M (=thread-selected,id="[0-9]+"^M |=(?:breakpoint-created|breakpoint-deleted)[^ ]+"^M )* FAIL: gdb.mi/mi-solib.exp: check for solib event (timeout) Looks like it is the test case should be revised to match the output, considering gdb_prompt is displaced in the middle of output.
Did you also enable async mode?
Yes, I set async mode on. The same fail still exists even when I turn non-stop off. Updated summary for this PR. Doesn't MI work well in async mode?
It does, but as you can see, the MI output in async mode is different. Look for all instances of "async" in mi-support.exp. So this test needs to be fixed somehow.
FYI, I'm working on this.
OK, I've drafted one patch, but not tested yet. Will start regression test for it. gdb: 2012-05-08 Yao Qi <yao@codesourcery.com> Fix PR mi/13860. * mi/mi-interp.c (mi_on_normal_stop): Print frame unconditionally. --- gdb/mi/mi-interp.c | 28 +++++++++++++--------------- 1 files changed, 13 insertions(+), 15 deletions(-) diff --git a/gdb/mi/mi-interp.c b/gdb/mi/mi-interp.c index daae480..1a2f266 100644 --- a/gdb/mi/mi-interp.c +++ b/gdb/mi/mi-interp.c @@ -438,26 +438,24 @@ mi_on_normal_stop (struct bpstats *bs, int print_frame) if (print_frame) { int core; + struct target_waitstatus last; + ptid_t last_ptid; + struct ui_out *saved_uiout = NULL; + int current_uiout_is_not_mi = (current_uiout != mi_uiout); - if (current_uiout != mi_uiout) - { - /* The normal_stop function has printed frame information - into CLI uiout, or some other non-MI uiout. There's no - way we can extract proper fields from random uiout - object, so we print the frame again. In practice, this - can only happen when running a CLI command in MI. */ - struct ui_out *saved_uiout = current_uiout; - struct target_waitstatus last; - ptid_t last_ptid; + get_last_target_status (&last_ptid, &last); + if (current_uiout_is_not_mi) + { + saved_uiout = current_uiout; current_uiout = mi_uiout; + } - get_last_target_status (&last_ptid, &last); - bpstat_print (bs, last.kind); + bpstat_print (bs, last.kind); + print_stack_frame (get_selected_frame (NULL), 0, SRC_AND_LOC); - print_stack_frame (get_selected_frame (NULL), 0, SRC_AND_LOC); - current_uiout = saved_uiout; - } + if (current_uiout_is_not_mi) + current_uiout = saved_uiout; ui_out_field_int (mi_uiout, "thread-id", pid_to_thread_id (inferior_ptid)); -- 1.7.0.4
I think there's more to it than this. - -exec-run vs "run" gives different MI output. - The ~"Stopped due to shared library event (no libraries added or removed)\n" bit is not output in async, when the user issues a CLI command. Or more generally, CLI execution commands don't produce output when the command finishes in async mode (e.g., "next"). I think they should, for the benefit of the user doing commands in the gdb console of a frontend (such as Eclipse).
(In reply to comment #6) > I think there's more to it than this. > > - -exec-run vs "run" gives different MI output. > Oh, I didn't notice this. > - The ~"Stopped due to shared library event (no libraries added or removed)\n" > bit is not output in async, when the user issues a CLI command. Or more Yes, I find this line doesn't exits in async gdb.log. > generally, CLI execution commands don't produce output when the command > finishes in async mode (e.g., "next"). I think they should, for the benefit of > the user doing commands in the gdb console of a frontend (such as Eclipse). That sounds like a serious problem, IMO. I agree with you that command output should be produced, no matter which mode (sync vs. async) gdb is running on. Existing mi test cases don't check much about CLI output, which should be improved.
(In reply to comment #7) > (In reply to comment #6) > > I think there's more to it than this. > > > > - -exec-run vs "run" gives different MI output. > > > > Oh, I didn't notice this. > > > - The ~"Stopped due to shared library event (no libraries added or removed)\n" > > bit is not output in async, when the user issues a CLI command. Or more > > Yes, I find this line doesn't exits in async gdb.log. > > > generally, CLI execution commands don't produce output when the command > > finishes in async mode (e.g., "next"). I think they should, for the benefit of > > the user doing commands in the gdb console of a frontend (such as Eclipse). > > That sounds like a serious problem, IMO. I agree with you that command output > should be produced, no matter which mode (sync vs. async) gdb is running on. > > Existing mi test cases don't check much about CLI output, which should be > improved. My patch posted in comment#5 fixes this fail, but causes some regressions in both sync mode and async mode, -PASS: gdb.mi/mi2-simplerun.exp: exec-finish +FAIL: gdb.mi/mi2-simplerun.exp: exec-finish (unknown output after running) -PASS: gdb.mi/mi-simplerun.exp: exec-finish +FAIL: gdb.mi/mi-simplerun.exp: exec-finish (unknown output after running) They are about the two points you mentioned in comment#6. You looked far ahead a little bit :)
Patch series posted: <http://sourceware.org/ml/gdb-patches/2012-05/msg00284.html>
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 0c7e1a4602a41a1caf637823f67948be31d27732 (commit) from a52e6fd34add3dbf267ac78e4d7912a0a3f65ece (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0c7e1a4602a41a1caf637823f67948be31d27732 commit 0c7e1a4602a41a1caf637823f67948be31d27732 Author: Pedro Alves <palves@redhat.com> Date: Tue Mar 18 17:50:28 2014 +0000 PR gdb/13860: make "-exec-foo"'s MI output equal to "foo"'s MI output. Part of PR gdb/13860 is about the mi-solib.exp test's output being different in sync vs async modes. sync: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17724" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3" (gdb) async: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async on" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) start &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17729" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" (gdb) *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1" For now, let's focus only on the *stopped event. We see that the async output is missing frame info. And this causes a test failure in async mode, as "mi_expect_stop solib-event" wants to see the frame info. However, if we compare the event output when a real MI execution command is used, compared to a CLI command (e.g., run vs -exec-run, next vs -exec-next, etc.), we see: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) r &"r\n" ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17751" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3" (gdb) -exec-run =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1" =library-unloaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",thread-group="i1" =thread-group-started,id="i1",pid="17754" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1" =thread-selected,id="1" (gdb) As seen above, with MI commands, the *stopped event _doesn't_ have frame info. This is because normal_stop, as commanded by the result of bpstat_print, skips printing frame info in this case (it's an "event", not a "breakpoint"), and when the interpreter is MI, mi_on_normal_stop skips calling print_stack_frame, as the normal_stop call was already done with the MI uiout. This explains why the async output is different even with a CLI command. Its because in async mode, the mi_on_normal_stop path is always taken; it is always reached with the MI uiout, because the stop is handled from the event loop, instead of from within `proceed -> wait_for_inferior -> normal_stop' with the interpreter overridden, as in sync mode. This patch fixes the issue by making all cases output the same *stopped event, by factoring out the print code from normal_stop, and using it from mi_on_normal_stop as well. I chose the *stopped output without a frame, mainly because that is what you already get if you use MI execution commands, the commands frontends are supposed to use (except when implementing a console). This patch makes it simpler to tweak the MI output differently if desired, as we only have to change the centralized print_stop_event (taking into account whether the uiout is MI-like), and all different modes will change accordingly. Tested on x86_64 Fedora 17, no regressions. The mi-solib.exp test no longer fails in async mode with this patch, so the patch removes the kfail. 2014-03-18 Pedro Alves <palves@redhat.com> PR gdb/13860 * inferior.h (print_stop_event): Declare. * infrun.c (print_stop_event): New, factored out from ... (normal_stop): ... this. * mi/mi-interp.c (mi_on_normal_stop): Use print_stop_event instead of bpstat_print/print_stack_frame. 2014-03-18 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdb.mi/mi-solib.exp: Remove gdb/13860 kfail. * lib/mi-support.exp (mi_expect_stop): Add special handling for solib-event. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 9 +++ gdb/inferior.h | 2 + gdb/infrun.c | 118 ++++++++++++++++++++----------------- gdb/mi/mi-interp.c | 3 +- gdb/testsuite/ChangeLog | 7 ++ gdb/testsuite/gdb.mi/mi-solib.exp | 4 - gdb/testsuite/lib/mi-support.exp | 18 +++++- 7 files changed, 98 insertions(+), 63 deletions(-)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 5166082f5f8ef80ec9840e1407e93d368da0b80f (commit) from 250748cb493a7bf942738c90f9ae6567e26c2b6b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5166082f5f8ef80ec9840e1407e93d368da0b80f commit 5166082f5f8ef80ec9840e1407e93d368da0b80f Author: Pedro Alves <palves@redhat.com> Date: Wed May 21 23:15:27 2014 +0100 PR gdb/13860: make -interpreter-exec console "list" behave more like "list". I noticed that "list" behaves differently in CLI vs MI. Particularly: $ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli...done. (gdb) start Temporary breakpoint 1 at 0x40054d: file ../../../src/gdb/testsuite/gdb.mi/basics.c, line 62. Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62 62 callee1 (2, "A string argument.", 3.5); (gdb) list 57 { 58 } 59 60 main () 61 { 62 callee1 (2, "A string argument.", 3.5); 63 callee1 (2, "A string argument.", 3.5); 64 65 do_nothing (); /* Hello, World! */ 66 (gdb) Note the list started at line 57. IOW, the program stopped at line 62, and GDB centered the list on that. compare with: $ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli..." ~"done.\n" (gdb) start &"start\n" ... ~"\nTemporary breakpoint " ~"1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62\n" ~"62\t callee1 (2, \"A string argument.\", 3.5);\n" *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x000000000040054d",func="main",args=[],file="../../../src/gdb/testsuite/gdb.mi/basics.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/basics.c",line="62"},thread-id="1",stopped-threads="all",core="0" =breakpoint-deleted,id="1" (gdb) -interpreter-exec console list ~"62\t callee1 (2, \"A string argument.\", 3.5);\n" ~"63\t callee1 (2, \"A string argument.\", 3.5);\n" ~"64\t\n" ~"65\t do_nothing (); /* Hello, World! */\n" ~"66\t\n" ~"67\t callme (1);\n" ~"68\t callme (2);\n" ~"69\t\n" ~"70\t return 0;\n" ~"71\t}\n" ^done (gdb) Here the list starts at line 62, where the program was stopped. This happens because print_stack_frame, called from both normal_stop and mi_on_normal_stop, is the function responsible for setting the current sal from the selected frame, overrides the PRINT_WHAT argument, and only after that does it decide whether to center the current sal line or not, based on the overridden value, and it will always decide false. (The print_stack_frame call in mi_on_normal_stop is a little different from the call in normal_stop, in that it is an unconditional SRC_AND_LOC call. A future patch will make those uniform.) A previous version of this patch made MI uniform with CLI here, by making print_stack_frame also center when MI is active. That changed the output of a "list" command in mi-cli.exp, to expect line 57 instead of 62, as per the example above. However, looking deeper, that list in question is the first "list" after the program stops, and right after the stop, before the "list", the test did "set listsize 1". Let's try the same thing with the CLI: (gdb) start 62 callee1 (2, "A string argument.", 3.5); (gdb) set listsize 1 (gdb) list 57 { Huh, that's unexpected. Why the 57? It's because print_stack_frame, called in reaction to the breakpoint stop, expecting the next "list" to show 10 lines (the listsize at the time) around line 62, sets the lines listed range to 57-67 (62 +/- 5). If the user changes the listsize before "list", why would we still show that range? Looks bogus to me. So the fix for this whole issue should be delay trying to center the listing to until actually listing, so that the correct listsize can be taken into account. This makes MI and CLI uniform too, as it deletes the center code from print_stack_frame. A series of tests are added to list.exp to cover this. mi-cli.exp was after all correct all along, but it now gains an additional test that lists lines with listsize 10, to ensure the centering is consistent with CLI's. One related Python test changed related output -- it's a test that prints the line number after stopping for a breakpoint, similar to the new list.exp tests. Previously we'd print the stop line minus 5 (due to the premature centering), now we print the stop line. I think that's a good change. Tested on x86_64 Fedora 20. gdb/ 2014-05-21 Pedro Alves <palves@redhat.com> * cli/cli-cmds.c (list_command): Handle the first "list" after the current source line having changed. * frame.h (set_current_sal_from_frame): Remove 'center' parameter. * infrun.c (normal_stop): Adjust call to set_current_sal_from_frame. * source.c (clear_lines_listed_range): New function. (set_current_source_symtab_and_line, identify_source_line): Clear the lines listed range. (line_info): Handle the first "info line" after the current source line having changed. * stack.c (print_stack_frame): Remove center handling. (set_current_sal_from_frame): Remove 'center' parameter. Don't center sal.line. gdb/testsuite/ 2014-05-21 Pedro Alves <palves@redhat.com> * gdb.base/list.exp (build_pattern, test_list): New procedures. Use them to test variations of "list" after reaching a breakpoint. * gdb.mi/mi-cli.exp (line_main_callme_2): New global. Test "list" with listsize 10 after reaching a breakpoint. * gdb.python/python.exp (decode_line current location line number): Adjust expected line number. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 16 ++++++ gdb/cli/cli-cmds.c | 21 ++++++++ gdb/frame.h | 5 +- gdb/infrun.c | 2 +- gdb/source.c | 26 ++++++++-- gdb/source.h | 7 ++- gdb/stack.c | 14 ++---- gdb/testsuite/ChangeLog | 9 +++ gdb/testsuite/gdb.base/list.exp | 95 +++++++++++++++++++++++++++++++++++ gdb/testsuite/gdb.mi/mi-cli.exp | 20 +++++++ gdb/testsuite/gdb.python/python.exp | 5 +- 11 files changed, 197 insertions(+), 23 deletions(-)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 17b2616cbab554fdd57e928d5ac9d742a7cbd2ec (commit) from 5166082f5f8ef80ec9840e1407e93d368da0b80f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=17b2616cbab554fdd57e928d5ac9d742a7cbd2ec commit 17b2616cbab554fdd57e928d5ac9d742a7cbd2ec Author: Pedro Alves <palves@redhat.com> Date: Tue Mar 11 20:31:36 2014 +0000 PR gdb/13860: don't lose '-interpreter-exec console EXECUTION_COMMAND''s output in async mode. The other part of PR gdb/13860 is about console execution commands in MI getting their output half lost. E.g., take the finish command, executed on a frontend's GDB console: sync: finish &"finish\n" ~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n" ^running *running,thread-id="1" (gdb) ~"0x00000000004004d7 in foo () at stepinf.c:6\n" ~"6\t usleep (10);\n" ~"Value returned is $1 = 0\n" *stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},thread-id="1",stopped-threads="all",core="1" async: finish &"finish\n" ~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n" ^running *running,thread-id="1" (gdb) *stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},gdb-result-var="$1",return-value="0",thread-id="1",stopped-threads="all",core="0" Note how all the "Value returned" etc. output is missing in async mode. The same happens with e.g., catchpoints: =breakpoint-modified,bkpt={number="1",type="catchpoint",disp="keep",enabled="y",what="22016",times="1"} ~"\nCatchpoint " ~"1 (forked process 22016), 0x0000003791cbd8a6 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131\n" ~"131\t pid = ARCH_FORK ();\n" *stopped,reason="fork",disp="keep",bkptno="1",newpid="22016",frame={addr="0x0000003791cbd8a6",func="__libc_fork",args=[],file="../nptl/sysdeps/unix/sysv/linux/fork.c",fullname="/usr/src/debug/glibc-2.14-394-g8f3b1ff/nptl/sysdeps/unix/sysv/linux/fork.c",line="131"},thread-id="1",stopped-threads="all",core="0" where all those ~ lines are missing in async mode, or just the "step" current line indication: s &"s\n" ^running *running,thread-id="all" (gdb) ~"13\t foo ();\n" *stopped,frame={addr="0x00000000004004ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffdd78"}],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="13"},thread-id="1",stopped-threads="all",core="3" (gdb) Or in the case of the PRs example, the "Stopped due to shared library event" note: start &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="21990" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="3" (gdb) IMO, if you're typing execution commands in a frontend's console, you expect to see their output. Indeed it's what you get in sync mode. I think async mode should do the same. Deciding what to mirror to the console wrt to breakpoints and random stops gets messy real fast. E.g., say "s" trips on a breakpoint. We'd clearly want to mirror the event to the console in this case. But what about more complicated cases like "s&; thread n; s&", and one of those steps spawning a new thread, and that thread hitting a breakpoint? It's impossible in general to track whether the thread had any relation to the commands that had been executed. So I think we should just simplify and always mirror breakpoints and random events to the console. Notes: - mi->out is the same as gdb_stdout when MI is the current interpreter. I think that referring to that directly is cleaner. An earlier revision of this patch made the changes that are now done in mi_on_normal_stop directly in infrun.c:normal_stop, and so not having an obvious place to put the new uiout by then, and not wanting to abuse CLI's uiout, I made a temporary uiout when necessary. - Hopefuly the rest of the patch is more or less obvious given the comments added. Tested on x86_64 Fedora 20, no regressions. 2014-05-21 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdbthread.h (struct thread_control_state): New field `command_interp'. * infrun.c (follow_fork): Copy the new thread control field to the child fork thread. (clear_proceed_status_thread): Clear the new thread control field. (proceed): Set the new thread control field. * interps.h (command_interp): Declare. * interps.c (command_interpreter): New global. (command_interp): New function. (interp_exec): Set `command_interpreter' while here. * cli-out.c (cli_uiout_dtor): New function. (cli_ui_out_impl): Install it. * mi/mi-interp.c: Include cli-out.h. (mi_cmd_interpreter_exec): Add comment. (restore_current_uiout_cleanup): New function. (ui_out_free_cleanup): New function. (mi_on_normal_stop): If finishing an execution command started by a CLI command, or any kind of breakpoint-like event triggered, print the stop event to the output (CLI) stream. * mi/mi-out.c (mi_ui_out_impl): Install NULL `dtor' handler. 2014-05-21 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdb.mi/mi-cli.exp (line_callee4_next_step): New global. (top level): Test that output related to execution commands is sent to the console with CLI commands, but not with MI commands. Test that breakpoint events are always mirrored to the console. Also expect the new source line to be output after a "next" in async mode too. Make it a pass/fail test. * gdb.mi/mi-solib.exp: Test that the CLI solib event note is output. * lib/mi-support.exp (mi_gdb_expect_cli_output): New procedure. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 24 +++++++++++ gdb/cli-out.c | 13 ++++++- gdb/gdbthread.h | 5 ++ gdb/infrun.c | 14 +++++++ gdb/interps.c | 36 +++++++++++++++++- gdb/interps.h | 2 + gdb/mi/mi-interp.c | 77 +++++++++++++++++++++++++++++++++++++ gdb/testsuite/ChangeLog | 13 ++++++ gdb/testsuite/gdb.mi/mi-cli.exp | 52 +++++++++++++++++++++--- gdb/testsuite/gdb.mi/mi-solib.exp | 11 +++++ gdb/testsuite/lib/mi-support.exp | 24 +++++++++++ 11 files changed, 262 insertions(+), 9 deletions(-)
I think this is finally fixed. Closing.
Oh, I forgot, there's more. From mi-cli.exp: # When a CLI command is entered in MI session, the respose is different in # sync and async modes. In sync mode normal_stop is called when current # interpreter is CLI. So: # - print_stop_reason prints stop reason in CLI uiout, and we don't show it # in MI # - The stop position is printed, and appears in MI 'console' channel. # # In async mode the stop event is processed when we're back to MI interpreter, # so the stop reason is printed into MI uiout an. if {$async} { set reason "end-stepping-range" } else { set reason "" } mi_execute_to "interpreter-exec console step" $reason "callee4" "" ".*basics.c" $line_callee4_next \ and: # Note that the output does not include stop reason. This is fine. # The purpose of *stopped notification for CLI command is to make # sure that frontend knows that inferior is stopped, and knows where. # Supplementary information is not necessary. mi_expect_stop "end-stepping-range" "main" "" ".*basics.c" $line_main_return "" \
I have a WIP patch for that.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via fd664c91769bf7e31c3b4d64e41d05854eecd94a (commit) from 8817a6f225766029787b5e2c1300a342b328909e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fd664c91769bf7e31c3b4d64e41d05854eecd94a commit fd664c91769bf7e31c3b4d64e41d05854eecd94a Author: Pedro Alves <palves@redhat.com> Date: Thu May 29 13:09:45 2014 +0100 PR gdb/13860 - Make MI sync vs async output (closer to) the same. Ignoring expected and desired differences like whether the prompt is output after *stoppped records, GDB MI output is still different in sync and async modes. In sync mode, when a CLI execution command is entered, the "reason" field is missing in the *stopped async record. And in async mode, for some events, like program exits, the corresponding CLI output is missing in the CLI channel. Vis, diff between sync vs async modes: run ^running *running,thread-id="1" (gdb) ... - ~"[Inferior 1 (process 15882) exited normally]\n" =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1",exit-code="0" - *stopped + *stopped,reason="exited-normally" si ... (gdb) ~"0x000000000045e033\t29\t memset (&args, 0, sizeof args);\n" - *stopped,frame=...,thread-id="1",stopped-threads="all",core="0" + *stopped,reason="end-stepping-range",frame=...,thread-id="1",stopped-threads="all",core="0" (gdb) In addition, in both cases, when a MI execution command is entered, and a breakpoint triggers, the event is sent to the console too. But some events like program exits have the CLI output missing in the CLI channel: -exec-run ^running *running,thread-id="1" (gdb) ... =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1",exit-code="0" - *stopped + *stopped,reason="exited-normally" We'll want to make background commands always possible by default. IOW, make target-async be the default. But, in order to do that, we'll need to emulate MI sync on top of an async target. That means we'll have yet another combination to care for in the testsuite. Rather than making the testsuite cope with all these differences, I thought it better to just fix GDB to always have the complete output, no matter whether it's in sync or async mode. This is all related to interpreter-exec, and the corresponding uiout switching. (Typing a CLI command directly in MI is shorthand for running it through -interpreter-exec console.) In sync mode, when a CLI command is active, normal_stop is called when the current interpreter and uiout are CLI's. So print_XXX_reason prints the stop reason to CLI uiout (only), and we don't show it in MI. In async mode the stop event is processed when we're back in the MI interpreter, so the stop reason is printed directly to the MI uiout. Fix this by making run control event printing roughly independent of whatever is the current interpreter or uiout. That is, move these prints to interpreter observers, that know whether to print or be quiet, and if printing, which uiout to print to. In the case of the console/tui interpreters, only print if the top interpreter. For MI, always print. Breakpoint hits / normal stops are already handled similarly -- MI has a normal_stop observer that prints the event to both MI and the CLI, though that could be cleaned up further in the direction of this patch. This also makes all of: (gdb) foo and (gdb) interpreter-exec MI "-exec-foo" and (gdb) -exec-foo and (gdb) -interpreter-exec console "foo" print as expected. Tested on x86_64 Fedora 20, sync and async modes. gdb/ 2014-05-29 Pedro Alves <palves@redhat.com> PR gdb/13860 * cli/cli-interp.c: Include infrun.h and observer.h. (cli_uiout, cli_interp): New globals. (cli_on_signal_received, cli_on_end_stepping_range) (cli_on_signal_exited, cli_on_exited, cli_on_no_history): New functions. (cli_interpreter_init): Install them as 'end_stepping_range', 'signal_received' 'signal_exited', 'exited' and 'no_history' observers. (_initialize_cli_interp): Remove cli_interp local. * infrun.c (handle_inferior_event): Call the several stop reason observers instead of printing the stop reason directly. (end_stepping_range): New function. (print_end_stepping_range_reason, print_signal_exited_reason) (print_exited_reason, print_signal_received_reason) (print_no_history_reason): Make static, and add an uiout parameter. Print to that instead of to CURRENT_UIOUT. * infrun.h (print_end_stepping_range_reason) (print_signal_exited_reason, print_exited_reason) (print_signal_received_reason print_no_history_reason): New declarations. * mi/mi-common.h (struct mi_interp): Rename 'uiout' field to 'mi_uiout'. <cli_uiout>: New field. * mi/mi-interp.c (mi_interpreter_init): Adjust. Create the new uiout for CLI output. Install 'signal_received', 'end_stepping_range', 'signal_exited', 'exited' and 'no_history' observers. (find_mi_interpreter, mi_interp_data, mi_on_signal_received) (mi_on_end_stepping_range, mi_on_signal_exited, mi_on_exited) (mi_on_no_history): New functions. (ui_out_free_cleanup): Delete function. (mi_on_normal_stop): Don't allocate a new uiout for CLI output, instead use the one already stored in the MI interpreter data. (mi_ui_out): Adjust. * tui/tui-interp.c: Include infrun.h and observer.h. (tui_interp): New global. (tui_on_signal_received, tui_on_end_stepping_range) (tui_on_signal_exited, tui_on_exited) (tui_on_no_history): New functions. (tui_init): Install them as 'end_stepping_range', 'signal_received' 'signal_exited', 'exited' and 'no_history' observers. (_initialize_tui_interp): Delete tui_interp local. gdb/doc/ 2014-05-29 Pedro Alves <palves@redhat.com> PR gdb/13860 * observer.texi (signal_received, end_stepping_range) (signal_exited, exited, no_history): New observer subjects. gdb/testsuite/ 2014-05-29 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdb.mi/mi-cli.exp: Always expect "end-stepping-range" stop reason, even in sync mode. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 47 +++++++++++++ gdb/cli/cli-interp.c | 64 +++++++++++++++++- gdb/doc/ChangeLog | 6 ++ gdb/doc/observer.texi | 20 ++++++ gdb/infrun.c | 118 ++++++++++++++++------------------ gdb/infrun.h | 22 ++++++ gdb/mi/mi-common.h | 5 +- gdb/mi/mi-interp.c | 136 +++++++++++++++++++++++++++++++++++---- gdb/testsuite/ChangeLog | 6 ++ gdb/testsuite/gdb.mi/mi-cli.exp | 23 +------ gdb/tui/tui-interp.c | 64 ++++++++++++++++++- 11 files changed, 408 insertions(+), 103 deletions(-)
I think now this is finally fixed. re-closing.