public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/13860] Fail in gdb.mi/mi-solib.exp in async mode
Date: Wed, 21 May 2014 22:17:00 -0000	[thread overview]
Message-ID: <bug-13860-4717-uRt7igawdK@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-13860-4717@http.sourceware.org/bugzilla/>

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.


  parent reply	other threads:[~2014-05-21 22:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-16  8:12 [Bug testsuite/13860] New: Fail in gdb.mi/mi-solib.exp when displaced stepping is on qiyao at gcc dot gnu.org
2012-03-16 10:14 ` [Bug testsuite/13860] " palves at redhat dot com
2012-03-16 10:46 ` [Bug testsuite/13860] Fail in gdb.mi/mi-solib.exp in async mode qiyao at gcc dot gnu.org
2012-03-16 10:53 ` palves at redhat dot com
2012-05-08 13:17 ` qiyao at gcc dot gnu.org
2012-05-08 13:22 ` palves at redhat dot com
2012-05-08 14:15 ` qiyao at gcc dot gnu.org
2012-05-08 14:25 ` palves at redhat dot com
2012-05-08 14:40 ` qiyao at gcc dot gnu.org
2012-05-09  8:04 ` qiyao at gcc dot gnu.org
2012-05-09 14:51 ` [Bug gdb/13860] " palves at redhat dot com
2012-05-09 17:25 ` palves at redhat dot com
2014-05-21 22:17 ` cvs-commit at gcc dot gnu.org [this message]
2014-05-21 22:36 ` cvs-commit at gcc dot gnu.org
2014-05-21 22:43 ` palves at redhat dot com
2014-05-22 10:54 ` [Bug gdb/13860] Different sync vs async MI output palves at redhat dot com
2014-05-22 10:55 ` palves at redhat dot com
2014-05-29 12:16 ` cvs-commit at gcc dot gnu.org
2014-05-29 12:46 ` palves at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-13860-4717-uRt7igawdK@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).