[Bug testsuite/13860] New: Fail in gdb.mi/mi-solib.exp when displaced stepping is on

[Bug testsuite/13860] New: Fail in gdb.mi/mi-solib.exp when displaced stepping is on

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

             Bug #: 13860
           Summary: Fail in gdb.mi/mi-solib.exp when displaced stepping is
                    on
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
        AssignedTo: unassigned@sourceware.org
        ReportedBy: qiyao@gcc.gnu.org
    Classification: Unclassified


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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp when displaced stepping is on

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> 2012-03-16 10:14:26 UTC ---
Did you also enable async mode?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Fail in gdb.mi/mi-solib.exp |Fail in gdb.mi/mi-solib.exp
                   |when displaced stepping is  |in async mode
                   |on                          |

--- Comment #2 from Yao Qi <qiyao at gcc dot gnu.org> 2012-03-16 10:45:43 UTC ---
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?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #3 from Pedro Alves <palves at redhat dot com> 2012-03-16 10:53:01 UTC ---
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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware    |qiyao at gcc dot gnu.org
                   |dot org                     |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #4 from Pedro Alves <palves at redhat dot com> 2012-05-08 13:22:19 UTC ---
FYI, I'm working on this.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #5 from Yao Qi <qiyao at gcc dot gnu.org> 2012-05-08 14:15:17 UTC ---
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

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #6 from Pedro Alves <palves at redhat dot com> 2012-05-08 14:25:05 UTC ---
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).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #7 from Yao Qi <qiyao at gcc dot gnu.org> 2012-05-08 14:40:19 UTC ---
(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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #8 from Yao Qi <qiyao at gcc dot gnu.org> 2012-05-09 08:03:52 UTC ---
(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 :)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/13860] Fail in gdb.mi/mi-solib.exp in async mode

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|testsuite                   |gdb

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/13860] Fail in gdb.mi/mi-solib.exp in async mode

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13860

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|qiyao at gcc dot gnu.org    |palves at redhat dot com

--- Comment #9 from Pedro Alves <palves at redhat dot com> 2012-05-09 17:25:03 UTC ---
Patch series posted:

<http://sourceware.org/ml/gdb-patches/2012-05/msg00284.html>

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/13860] Fail in gdb.mi/mi-solib.exp in async mode

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/13860] Fail in gdb.mi/mi-solib.exp in async mode

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #12 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/13860] Fail in gdb.mi/mi-solib.exp in async mode

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13860

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.8

--- Comment #13 from Pedro Alves <palves at redhat dot com> ---
I think this is finally fixed.  Closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/13860] Different sync vs async MI output

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13860

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---
            Summary|Fail in gdb.mi/mi-solib.exp |Different sync vs async MI
                   |in async mode               |output

--- Comment #14 from Pedro Alves <palves at redhat dot com> ---
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 ""
\

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/13860] Different sync vs async MI output

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #15 from Pedro Alves <palves at redhat dot com> ---
I have a WIP patch for that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/13860] Different sync vs async MI output

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13860

--- Comment #16 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/13860] Different sync vs async MI output

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13860

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #17 from Pedro Alves <palves at redhat dot com> ---
I think now this is finally fixed.  re-closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.