gdb and binutils branch master updated. 251bde03baf93dbb44d3785e09e03179916143e3

[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  251bde03baf93dbb44d3785e09e03179916143e3 (commit)
      from  434415618f6bb9ac428a8d18ab33111920cd04dc (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=251bde03baf93dbb44d3785e09e03179916143e3

commit 251bde03baf93dbb44d3785e09e03179916143e3
Author: Pedro Alves <palves@redhat.com>
Date:   Thu May 29 12:27:01 2014 +0100

    PR15693 - Fix spurious *running events, thread state, dprintf-style call
    
    If one sets a breakpoint with a condition that involves calling a
    function in the inferior, and then the condition evaluates false, GDB
    outputs one *running event for each time the program hits the
    breakpoint.  E.g.,
    
      $ gdb return-false -i=mi
    
      (gdb)
      start
      ...
      (gdb)
      b 14 if return_false ()
      &"b 14 if return_false ()\n"
      ~"Breakpoint 2 at 0x4004eb: file return-false.c, line 14.\n"
      ...
      ^done
      (gdb)
      c
      &"c\n"
      ~"Continuing.\n"
      ^running
      *running,thread-id=(...)
      (gdb)
      *running,thread-id=(...)
      *running,thread-id=(...)
      *running,thread-id=(...)
      *running,thread-id=(...)
      *running,thread-id=(...)
      ... repeat forever ...
    
    An easy way a user can trip on this is with a dprintf with "set
    dprintf-style call".  In that case, a dprintf is just a breakpoint
    that when hit GDB calls the printf function in the inferior, and then
    resumes it, just like the case above.
    
    If the breakpoint/dprintf is set in a loop, then these spurious events
    can potentially slow down a frontend much, if it decides to refresh
    its GUI whenever it sees this event (Eclipse is one such case).
    
    When we run an infcall, we pretend we don't actually run the inferior.
    This is already handled for the usual case of calling a function
    directly from the CLI:
    
     (gdb)
     p return_false ()
     &"p return_false ()\n"
     ~"$1 = 0"
     ~"\n"
     ^done
     (gdb)
    
    Note no *running, nor *stopped events.  That's handled by:
    
     static void
     mi_on_resume (ptid_t ptid)
     {
    ...
       /* Suppress output while calling an inferior function.  */
       if (tp->control.in_infcall)
         return;
    
    and equivalent code on normal_stop.
    
    However, in the cases of the PR, after finishing the infcall there's
    one more resume, and mi_on_resume doesn't know that it should suppress
    output then too, somehow.
    
    The "running/stopped" state is a high level user/frontend state.
    Internal stops are invisible to the frontend.  If follows from that
    that we should be setting the thread to running at a higher level
    where we still know the set of threads the user _intends_ to resume.
    
    Currently we mark a thread as running from within target_resume, a low
    level target operation.  As consequence, today, if we resume a
    multi-threaded program while stopped at a breakpoint, we see this:
    
     -exec-continue
     ^running
     *running,thread-id="1"
     (gdb)
     *running,thread-id="all"
    
    The first *running was GDB stepping over the breakpoint, and the
    second is GDB finally resuming everything.
    
    Between those two *running's, threads other than "1" still have their
    state set to stopped.  That's bogus -- in async mode, this opens a
    tiny window between both resumes where the user might try to run
    another execution command to threads other than thread 1, and very
    much confuse GDB.
    
    That is, the "step" below should fail the "step", complaining that the
    thread is running:
    
      (gdb) c -a &
      (gdb) thread 2
      (gdb) step
    
    IOW, threads that GDB happens to not resume immediately (say, because
    it needs to step over a breakpoint) shall still be marked as running.
    
    Then, if we move marking threads as running to a higher layer,
    decoupled from target_resume, plus skip marking threads as running
    when running an infcall, the spurious *running events disappear,
    because there will be no state transitions at all.
    
    I think we might end up adding a new thread state -- THREAD_INFCALL or
    some such, however since infcalls are always synchronous today, I
    didn't find a need.  There's no way to execute a CLI/MI command
    directly from the prompt if some thread is running an infcall.
    
    Tested on x86_64 Fedora 20.
    
    gdb/
    2014-05-29  Pedro Alves  <palves@redhat.com>
    
    	PR PR15693
    	* infrun.c (resume): Determine how much to resume depending on
    	whether the caller wanted a step, not whether we can hardware step
    	the target.  Mark all threads that we intend to run as running,
    	unless we're calling an inferior function.
    	(normal_stop): If the thread is running an infcall, don't finish
    	thread state.
    	* target.c (target_resume): Don't mark threads as running here.
    
    gdb/testsuite/
    2014-05-29  Pedro Alves  <palves@redhat.com>
    	    Hui Zhu  <hui@codesourcery.com>
    
    	PR PR15693
    	* gdb.mi/mi-condbreak-call-thr-state-mt.c: New file.
    	* gdb.mi/mi-condbreak-call-thr-state-st.c: New file.
    	* gdb.mi/mi-condbreak-call-thr-state.c: New file.
    	* gdb.mi/mi-condbreak-call-thr-state.exp: New file.

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

Summary of changes:
 gdb/ChangeLog                                      |   11 ++
 gdb/infrun.c                                       |   44 ++++++--
 gdb/target.c                                       |    3 +-
 gdb/testsuite/ChangeLog                            |    9 ++
 .../gdb.mi/mi-condbreak-call-thr-state-mt.c        |   61 ++++++++++
 .../gdb.mi/mi-condbreak-call-thr-state-st.c        |   26 +++++
 gdb/testsuite/gdb.mi/mi-condbreak-call-thr-state.c |   33 ++++++
 .../gdb.mi/mi-condbreak-call-thr-state.exp         |  116 ++++++++++++++++++++
 8 files changed, 291 insertions(+), 12 deletions(-)
 create mode 100644 gdb/testsuite/gdb.mi/mi-condbreak-call-thr-state-mt.c
 create mode 100644 gdb/testsuite/gdb.mi/mi-condbreak-call-thr-state-st.c
 create mode 100644 gdb/testsuite/gdb.mi/mi-condbreak-call-thr-state.c
 create mode 100644 gdb/testsuite/gdb.mi/mi-condbreak-call-thr-state.exp


hooks/post-receive
-- 
gdb and binutils