gdb and binutils branch master updated. e8af5d7a5cd4c58136a4733e87612f49061bf28b

[brobecke 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  e8af5d7a5cd4c58136a4733e87612f49061bf28b (commit)
      from  a344fc094daa257557786eb2ce871debf38456ba (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=e8af5d7a5cd4c58136a4733e87612f49061bf28b

commit e8af5d7a5cd4c58136a4733e87612f49061bf28b
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Thu Nov 20 20:41:25 2014 +0400

    Always consider infcall breakpoints as non-permanent.
    
    A recent change...
    
        commit 1a853c5224e2b8fedfac6d029365522b83080b40
        Date:   Wed Nov 12 10:10:49 2014 +0000
        Subject: make "permanent breakpoints" per location and disableable
    
    ... broke function calls on sparc-elf when running over QEMU. Any
    function call should demonstrate the problem.
    
    For instance, seen from the debugger:
    
        (gdb) call pn(1234)
        [Inferior 1 (Remote target) exited normally]
        The program being debugged exited while in a function called from GDB.
        Evaluation of the expression containing the function
    
    And seen from QEMU:
    
        qemu: fatal: Trap 0x02 while interrupts disabled, Error state
        [register dump removed]
    
    What happens in this case is that GDB sets the inferior function call
    by not only creating the dummy frame, but also writing a breakpoint
    instruction at the return address for our function call. See infcall.c:
    
            /* Write a legitimate instruction at the point where the infcall
               breakpoint is going to be inserted.  While this instruction
               is never going to be executed, a user investigating the
               memory from GDB would see this instruction instead of random
               uninitialized bytes.  We chose the breakpoint instruction
               as it may look as the most logical one to the user and also
               valgrind 3.7.0 needs it for proper vgdb inferior calls.
    
               If software breakpoints are unsupported for this target we
               leave the user visible memory content uninitialized.  */
    
            bp_addr_as_address = bp_addr;
            bp_bytes = gdbarch_breakpoint_from_pc (gdbarch, &bp_addr_as_address,
                                                   &bp_size);
            if (bp_bytes != NULL)
              write_memory (bp_addr_as_address, bp_bytes, bp_size);
    
    This instruction triggers a change introduced by the commit above,
    where we consider bp locations as being permanent breakpoints
    if there is already a breakpoint instruction at that address:
    
            +  if (bp_loc_is_permanent (loc))
            +    {
            +      loc->inserted = 1;
            +      loc->permanent = 1;
            +    }
    
    As a result, when resuming the program's execution for the inferior
    function call, GDB decides that it does not need to insert a breakpoint
    at this address, expecting the target to just report a SIGTRAP when
    trying to execute that instruction.
    
    But unfortunately for us, at least some versions of QEMU for SPARC
    just terminate the execution entirely instead of reporting a breakpoint,
    thus producing the behavior reported here.
    
    Although it appears like QEMU might be misbehaving and should therefore
    be fixed (to be verified) from the user's point of view, the recent
    change does introduce a regression. So this patch tries to mitigate
    a bit the damage by handling such infcall breakpoints as special and
    making sure that they are never considered permanent, thus restoring
    the previous behavior specifically for those breakpoints.
    
    The option of not writing the breakpoint instructions in the first
    place was considered, and would probably work also. But the comment
    associated to it seems to indicate that there is still reason to
    keep it.
    
    gdb/ChangeLog:
    
            * breakpoint.c (bp_loc_is_permanent): Return 0 if LOC corresponds
            to a bp_call_dummy breakpoint type.
    
    Tested on x86_64-linux. Also testing on sparc-elf/QEMU using
    AdaCore's testsuite.

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

Summary of changes:
 gdb/ChangeLog    |    5 +++++
 gdb/breakpoint.c |   14 ++++++++++++++
 2 files changed, 19 insertions(+), 0 deletions(-)


hooks/post-receive
-- 
gdb and binutils