gdb and binutils branch master updated. 483805cf9ea5a6dace41415d8830e93fccc49c43

[palves at sourceware dot 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  483805cf9ea5a6dace41415d8830e93fccc49c43 (commit)
      from  06d9754365774595eae45a8548d5f24d7093006c (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=483805cf9ea5a6dace41415d8830e93fccc49c43

commit 483805cf9ea5a6dace41415d8830e93fccc49c43
Author: Pedro Alves <palves@redhat.com>
Date:   Tue Apr 22 15:00:56 2014 +0100

    Consecutive step-overs trigger internal error.
    
    If a thread trips on a breakpoint that needs stepping over just after
    finishing a step over, GDB currently fails an assertion.  This is a
    regression caused by the "Handle multiple step-overs." patch
    (99619beac6252113fed212fdb9e1ab97bface423) at
    https://sourceware.org/ml/gdb-patches/2014-02/msg00765.html.
    
     (gdb) x /4i $pc
     => 0x400540 <main+4>:   movl   $0x0,0x2003da(%rip)        # 0x600924 <i>
        0x40054a <main+14>:  movl   $0x1,0x2003d0(%rip)        # 0x600924 <i>
        0x400554 <main+24>:  movl   $0x2,0x2003c6(%rip)        # 0x600924 <i>
        0x40055e <main+34>:  movl   $0x3,0x2003bc(%rip)        # 0x600924 <i>
     (gdb) PASS: gdb.base/consecutive-step-over.exp: get breakpoint addresses
     break *0x40054a
     Breakpoint 2 at 0x40054a: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 23.
     (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set breakpoint
     condition $bpnum condition
     (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set condition
     break *0x400554
     Breakpoint 3 at 0x400554: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 24.
     (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set breakpoint
     condition $bpnum condition
     (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set condition
     break *0x40055e
     Breakpoint 4 at 0x40055e: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 25.
     (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set breakpoint
     condition $bpnum condition
     (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set condition
     break 27
     Breakpoint 5 at 0x400568: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 27.
     (gdb) continue
     Continuing.
     ../../src/gdb/infrun.c:5200: internal-error: switch_back_to_stepped_thread: Assertion `!tp->control.trap_expected' failed.
     A problem internal to GDB has been detected,
     further debugging may prove unreliable.
     FAIL: gdb.base/consecutive-step-over.exp: continue to breakpoint: break here (GDB internal error)
    
    The assertion fails, because the code is not expecting that the event
    thread itself might need another step over.  IOW, not expecting that
    TP in:
    
         tp = find_thread_needs_step_over (stepping_thread != NULL,
                                          stepping_thread);
    
    could be the event thread.
    
    A small fix for this would be to clear the event thread's
    trap_expected earlier, before asserting.  But looking deeper, although
    currently_stepping_or_nexting_callback's intention is finding the
    thread that is doing a step/next, it also returns the thread that is
    doing a step-over dance, with trap_expected set.  If there ever was a
    reason for that (it was I who added
    currently_stepping_or_nexting_callback , but I can't recall why I put
    trap_expected there in the first place), the only remaining reason
    nowadays is to aid in implementing switch_back_to_stepped_thread's
    assertion that is now triggering, by piggybacking on the walk over all
    threads, thus avoiding a separate walk.  This is quite obscure, and I
    think we can do even better, by merging the walks that look for the
    stepping thread, and the walk that looks for some thread that might
    need a step over.
    
    Tested on x86_64 Fedora 17, native and gdbserver, and also native on
    top of my "software single-step on x86_64" series.
    
    gdb/
    2014-04-22  Pedro Alves  <palves@redhat.com>
    
    	* infrun.c (schedlock_applies): New function, factored out from
    	find_thread_needs_step_over.
    	(find_thread_needs_step_over): Use it.
    	(switch_back_to_stepped_thread): Always clear trap_expected if the
    	step over is finished.  Return early if scheduler locking applies.
    	Look for the stepping thread and a potential step-over thread with
    	a single loop.
    	(currently_stepping_or_nexting_callback): Delete.
    
    2014-04-22  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/consecutive-step-over.c: New file.
    	* gdb.base/consecutive-step-over.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                    |   11 ++
 gdb/infrun.c                                     |  125 ++++++++++++++--------
 gdb/testsuite/ChangeLog                          |    5 +
 gdb/testsuite/gdb.base/consecutive-step-over.c   |   28 +++++
 gdb/testsuite/gdb.base/consecutive-step-over.exp |   70 ++++++++++++
 5 files changed, 195 insertions(+), 44 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/consecutive-step-over.c
 create mode 100644 gdb/testsuite/gdb.base/consecutive-step-over.exp


hooks/post-receive
-- 
gdb and binutils