gdb and binutils branch master updated. 076855f9e36ecfe8af325b197e9ecd46deb9fe6c

[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  076855f9e36ecfe8af325b197e9ecd46deb9fe6c (commit)
      from  8a52f0d9837ae191eb6d85ded55d3a04da3b7f12 (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=076855f9e36ecfe8af325b197e9ecd46deb9fe6c

commit 076855f9e36ecfe8af325b197e9ecd46deb9fe6c
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Apr 23 15:06:47 2014 +0100

    Don't suppress errors inserting/removing hardware breakpoints in shared
    libraries.
    
    As explained in
    https://sourceware.org/ml/gdb-patches/2008-08/msg00361.html, after a
    shared library was unloaded, we can no longer insert or remove
    breakpoints into/from its (no longer present) code segment.  That'll
    fail with memory errors.  However, that concern does not apply to
    hardware breakpoints.  By definition, hardware breakpoints are
    implemented using a mechanism that is not dependent on being able to
    modify the target's memory.  Usually, by setting up CPU debug
    registers.  IOW, we should be able to set hw breakpoints in an
    unmapped address.  We don't seem to have a test that exercises that,
    so this patch adds one.
    
    I noticed the error supression because of a related issue -- the
    target_insert_hw_breakpoint/target_remove_hw_breakpoint interfaces
    don't really distinguish "not supported" from "error" return, and so
    remote.c returns -1 in both cases.  This results in hardware
    breakpoints set in shared libraries silently ending up pending forever
    even though the target doesn't actually support hw breakpoints.
    
     (gdb) set breakpoint always-inserted on
     (gdb) set remote Z-packet off
     (gdb) info breakpoints
     No breakpoints or watchpoints.
     (gdb) hbreak shrfunc
     Hardware assisted breakpoint 3 at 0x7ffff7dfb657: file ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c, line 21.
     (gdb) info break
     Num     Type           Disp Enb Address            What
     3       hw breakpoint  keep y   <PENDING>          shrfunc
    
    After the patch we get the expected:
    
     (gdb) hbreak shrfunc
     Hardware assisted breakpoint 3 at 0x7ffff7dfb657: file ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c, line 21.
     Warning:
     Cannot insert hardware breakpoint 3.
     Could not insert hardware breakpoints:
     You may have requested too many hardware breakpoints/watchpoints.
    
     (gdb) info break
     Num     Type           Disp Enb Address            What
     3       hw breakpoint  keep y   0x00007ffff7dfb657 in shrfunc at ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c:21
    
    (HW breakpoints set in the main executable, when the target doesn't
    support HW breakpoints always resulted in the latter output.)
    
    We probably should improve the insert/remove interface to return a
    different error code for unsupported.  But I chose to fix the error
    supression first, as it's a deeper and wider issue.
    
    Tested on x86_64 Fedora 17, native and gdbserver.
    
    gdb/
    2014-04-23  Pedro Alves  <palves@redhat.com>
    
    	* breakpoint.c (insert_bp_location, remove_breakpoint_1): If
    	the breakpoint is set in a shared library, only suppress
    	errors for software breakpoints, not hardware breakpoints.
    
    gdb/testsuite/
    2014-04-23  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/hbreak-in-shr-unsupported-shr.c: New file.
    	* gdb.base/hbreak-in-shr-unsupported.c: New file.
    	* gdb.base/hbreak-in-shr-unsupported.exp: New file.
    	* gdb.base/hbreak-unmapped.c: New file.
    	* gdb.base/hbreak-unmapped.exp: New file.
    	* gdb.trace/qtro.exp (gdb_is_target_remote): Move ...
    	* lib/gdb.exp (gdb_is_target_remote): ... here.

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

Summary of changes:
 gdb/ChangeLog                                      |    6 +
 gdb/breakpoint.c                                   |   14 ++-
 gdb/testsuite/ChangeLog                            |   10 ++
 .../gdb.base/hbreak-in-shr-unsupported-shr.c       |   22 ++++
 gdb/testsuite/gdb.base/hbreak-in-shr-unsupported.c |   28 +++++
 .../gdb.base/hbreak-in-shr-unsupported.exp         |  120 ++++++++++++++++++++
 .../gdb.base/{auto-load.c => hbreak-unmapped.c}    |    0
 gdb/testsuite/gdb.base/hbreak-unmapped.exp         |   72 ++++++++++++
 gdb/testsuite/gdb.trace/qtro.exp                   |   16 ---
 gdb/testsuite/lib/gdb.exp                          |   19 +++
 10 files changed, 285 insertions(+), 22 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c
 create mode 100644 gdb/testsuite/gdb.base/hbreak-in-shr-unsupported.c
 create mode 100644 gdb/testsuite/gdb.base/hbreak-in-shr-unsupported.exp
 copy gdb/testsuite/gdb.base/{auto-load.c => hbreak-unmapped.c} (100%)
 create mode 100644 gdb/testsuite/gdb.base/hbreak-unmapped.exp


hooks/post-receive
-- 
gdb and binutils