gdb and binutils branch master updated. 4ae57c052202642ac2976a4ce8929a14d3eb3d12

[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  4ae57c052202642ac2976a4ce8929a14d3eb3d12 (commit)
      from  329ea57934a9d4b250a0b417af1ec47bc2d0ceb6 (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=4ae57c052202642ac2976a4ce8929a14d3eb3d12

commit 4ae57c052202642ac2976a4ce8929a14d3eb3d12
Author: Pedro Alves <palves@redhat.com>
Date:   Thu May 29 17:17:30 2014 +0100

    unbreak infcalls
    
    I managed to miss an interaction between the recent *running patch,
    and target-async, which resulted in infcalls being completely broken
    on GNU/Linux and remote targets (that is, the async-capable targets).
    
     Temporary breakpoint 1, main () at threads.c:35
     35          long i = 0;
     (gdb) p malloc (0)
     The program being debugged stopped while in a function called from GDB.
     Evaluation of the expression containing the function
     (malloc) will be abandoned.
     When the function is done executing, GDB will silently stop.
     (gdb) p malloc (0)
    
     Program received signal SIGSEGV, Segmentation fault.
     0x000000000058d7e8 in get_regcache_aspace (regcache=0x0) at ../../src/gdb/regcache.c:281
     281       return regcache->aspace;
     (top-gdb)
    
    The issue is that when running an infcall, the thread is no longer
    marked as running, so run_inferior_call is not calling
    wait_for_inferior anymore.
    
    Fix this by doing what the comment actually says we do:
    
      "Do here what `proceed' itself does in sync mode."
    
    And proceed doesn't check whether the target is running.
    
    I notice this is broken in case of the early return in proceed, but we
    were broken before in that case anyway, because run_inferior_call will
    think the call actually ran.  Seems like we should make proceed have a
    boolean return, and go through all callers making use of it, if
    necessary.
    
    But for now, just fix the regression.
    
    Tested on x86_64 Fedora 20.
    
    gdb/
    2014-05-29  Pedro Alves  <palves@redhat.com>
    
    	* infcall.c (run_inferior_call): Don't check whether the current
    	thread is running after the proceed call.

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

Summary of changes:
 gdb/ChangeLog |    5 +++++
 gdb/infcall.c |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
gdb and binutils