gdb and binutils branch master updated. 08351840eabb44799e3d01026610420758f4fa40

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

commit 08351840eabb44799e3d01026610420758f4fa40
Author: Pedro Alves <palves@redhat.com>
Date:   Tue Apr 22 23:19:19 2014 +0100

    Stale breakpoint instructions, spurious SIGTRAPS.
    
    Without the code portion of the patch, we get these failures:
    
     FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue
     FAIL: gdb.base/break-unload-file.exp: always-inserted on: hbreak: continue
     FAIL: gdb.base/sym-file.exp: stale bkpts: continue to breakpoint: end here
    
    They all looks like random SIGTRAPs:
    
     continue
     Continuing.
    
     Program received signal SIGTRAP, Trace/breakpoint trap.
     0x0000000000400541 in foo () at ../../../src/gdb/testsuite/gdb.base/break-unload-file.c:21
     21      }
     (gdb) FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue
    
    (This is a regression caused by the remove-symbol-file command
    series.)
    
    break-unload-file.exp is about having breakpoints inserted, and then
    doing "file".  I caught this while writing a test that does "file
    PROGRAM", while PROGRAM was already loaded, which internally does
    "file" first, because I wanted to force a breakpoint_re_set, but the
    test is more explicit in case GDB ever optimizes out that re-set.
    
    The problem is that unloading the file with "file" ends up in
    disable_breakpoints_in_freed_objfile, which marks all breakpoint
    locations of the objfile as both shlib_disabled, _and_ clears the
    inserted flag, without actually removing the breakpoints from the
    inferior.  Now, usually, in all-stop, breakpoints will already be
    removed from the inferior before the user can issue the "file"
    command, but, with non-stop, or breakpoints always-inserted on mode,
    breakpoints stay inserted even while the user has the prompt.  In the
    latter case, then, if we let the program continue, and it executes the
    address where we had previously set the breakpoint, it'll actually
    execute the breakpoint instruction that we left behind...
    
    Now, one issue is that the intent of
    disable_breakpoints_in_freed_objfile is really to handle the unloading
    of OBJF_USERLOADED objfiles.  These are objfiles that were added with
    add-symbol-file and that are removed with remove-symbol-file.
    
    "add-symbol-file"'s docs in the manual clearly say these commands are
    used to let GDB know about dynamically loaded code:
    
     You would use this command when @var{filename} has been dynamically
     loaded (by some other means) into the program that is running.
    
    Similarly, the online help says:
    
     (gdb) help add-symbol-file
     Load symbols from FILE, assuming FILE has been dynamically loaded.
    
    So it makes sense to, like when shared libraries are unloaded through
    the generic solib machinery, mark the breakpoint locations as
    shlib_disabled.  But, the "file" command is not about dynamically
    loaded code, it's about the main program.  So the patch makes
    disable_breakpoints_in_freed_objfile skip all objfiles but
    OBJF_USERLOADED ones, thus skipping the main objfile.
    
    Then, the reason that disable_breakpoints_in_freed_objfile was
    clearing the inserted flag isn't clear, but likely to avoid breakpoint
    removal errors, assuming remove-symbol-file was called after the
    dynamic object was already unmapped from the inferior.  In that case,
    it'd okay to simply clear the inserted flag, but not so if the user
    for example does remove-symbol-file to remove the library because he
    made a mistake in the library's address, and wants to re-do
    add-symbol-file with the correct address.
    
    To address all that, I propose an alternative implementation, that
    handles both cases.  The patch includes changes to sym-file.exp to
    cover them.
    
    This implementation leaves the inserted flag alone, and handles
    breakpoint insertion/removal failure gracefully when the locations are
    in OBJF_USERLOADED objfiles, just like we handle insertion/removal
    failure gracefully for locations in shared libraries.
    
    To try to make sure we aren't patching back stale shadow memory
    contents into the inferior, in case the program mapped a different
    library at the same address where we had the breakpoint, without the
    user having had a chance of remove-symbol-file'ing before, this adds a
    new memory_validate_breakpoint function that checks if the breakpoint
    instruction is still in memory.  ppc_linux_memory_remove_breakpoint
    does this unconditionally for all memory breakpoints, and questions
    whether memory_remove_breakpoint should be changed to do this for all
    breakpoints.  Possibly yes, though I'm not certain, hence this
    baby-steps patch.
    
    Tested on x86_64 Fedora 17, native and gdbserver.
    
    gdb/
    2014-04-23  Pedro Alves  <palves@redhat.com>
    
    	* breakpoint.c (insert_bp_location): Tolerate errors if the
    	breakpoint is set in a user-loaded objfile.
    	(remove_breakpoint_1): Likewise.  Also tolerate errors if the
    	location is marked shlib_disabled.  If the breakpoint is set in a
    	user-loaded objfile is a GDB-side memory breakpoint, validate it
    	before uninsertion.  (disable_breakpoints_in_freed_objfile): Skip
    	non-OBJF_USERLOADED objfiles.  Don't clear the location's inserted
    	flag.
    	* mem-break.c (memory_validate_breakpoint): New function.
    	* objfiles.c (userloaded_objfile_contains_address_p): New
    	function.
    	* objfiles.h (userloaded_objfile_contains_address_p): Declare.
    	* target.h (memory_validate_breakpoint): New declaration.
    
    gdb/testsuite/
    2014-04-23  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/break-unload-file.c: New file.
    	* gdb.base/break-unload-file.exp: New file.
    	* gdb.base/sym-file-lib.c (baz): New function.
    	* gdb.base/sym-file-loader.c (struct segment) <mapped_size>: New
    	field.
    	(load): Store the segment's mapped size.
    	(unload): New function.
    	(unload_shlib): New function.
    	* gdb.base/sym-file-loader.h (unload_shlib): New declaration.
    	* gdb.base/sym-file-main.c (main): Unload, and reload the library,
    	set a breakpoint at baz, and call it.
    	* gdb.base/sym-file.exp: New tests for stale breakpoint
    	instructions.

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

Summary of changes:
 gdb/ChangeLog                                |   16 +++
 gdb/breakpoint.c                             |   71 ++++++++++++---
 gdb/mem-break.c                              |   32 +++++++
 gdb/objfiles.c                               |   16 +++
 gdb/objfiles.h                               |    7 ++
 gdb/target.h                                 |    6 +
 gdb/testsuite/ChangeLog                      |   16 +++
 gdb/testsuite/gdb.base/break-unload-file.c   |   35 +++++++
 gdb/testsuite/gdb.base/break-unload-file.exp |  128 ++++++++++++++++++++++++++
 gdb/testsuite/gdb.base/sym-file-lib.c        |    6 +
 gdb/testsuite/gdb.base/sym-file-loader.c     |   28 ++++++
 gdb/testsuite/gdb.base/sym-file-loader.h     |    4 +
 gdb/testsuite/gdb.base/sym-file-main.c       |   26 +++++-
 gdb/testsuite/gdb.base/sym-file.exp          |   49 ++++++++++-
 14 files changed, 425 insertions(+), 15 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/break-unload-file.c
 create mode 100644 gdb/testsuite/gdb.base/break-unload-file.exp


hooks/post-receive
-- 
gdb and binutils