This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb and binutils branch gdb-7.7-branch updated. gdb-7.7-release-35-g66bb3d1


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, gdb-7.7-branch has been updated
       via  66bb3d16d4c7b92426136c99199aab79099e32cb (commit)
      from  79a33da92acb5c497d9dd045f23c38fd9eff6911 (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=66bb3d16d4c7b92426136c99199aab79099e32cb

commit 66bb3d16d4c7b92426136c99199aab79099e32cb
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Mar 5 14:18:28 2014 +0000

    PR gdb/16575: stale breakpoint instructions in the code cache
    
    In non-stop mode, or rather, breakpoints always-inserted mode, the
    code cache can easily end up with stale breakpoint instructions:
    
    All it takes is filling a cache line when breakpoints already exist in
    that memory region, and then delete the breakpoint.
    
    Vis. (from the new test):
    
     (gdb) set breakpoint always-inserted on
     (gdb) b 23
     Breakpoint 2 at 0x400540: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 23.
     (gdb) b 24
     Breakpoint 3 at 0x400547: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 24.
     disass main
     Dump of assembler code for function main:
        0x000000000040053c <+0>:     push   %rbp
        0x000000000040053d <+1>:     mov    %rsp,%rbp
     => 0x0000000000400540 <+4>:     movl   $0x1,-0x4(%rbp)
        0x0000000000400547 <+11>:    movl   $0x2,-0x4(%rbp)
        0x000000000040054e <+18>:    mov    $0x0,%eax
        0x0000000000400553 <+23>:    pop    %rbp
        0x0000000000400554 <+24>:    retq
     End of assembler dump.
    
    So far so good.  Now flush the code cache:
    
     (gdb) set code-cache off
     (gdb) set code-cache on
    
    Requesting a disassembly works as expected, breakpoint shadowing is
    applied:
    
     (gdb) disass main
     Dump of assembler code for function main:
        0x000000000040053c <+0>:     push   %rbp
        0x000000000040053d <+1>:     mov    %rsp,%rbp
     => 0x0000000000400540 <+4>:     movl   $0x1,-0x4(%rbp)
        0x0000000000400547 <+11>:    movl   $0x2,-0x4(%rbp)
        0x000000000040054e <+18>:    mov    $0x0,%eax
        0x0000000000400553 <+23>:    pop    %rbp
        0x0000000000400554 <+24>:    retq
     End of assembler dump.
    
    However, now delete the breakpoints:
    
     (gdb) delete
     Delete all breakpoints? (y or n) y
    
    And disassembly shows the old breakpoint instructions:
    
     (gdb) disass main
     Dump of assembler code for function main:
        0x000000000040053c <+0>:     push   %rbp
        0x000000000040053d <+1>:     mov    %rsp,%rbp
     => 0x0000000000400540 <+4>:     int3
        0x0000000000400541 <+5>:     rex.RB cld
        0x0000000000400543 <+7>:     add    %eax,(%rax)
        0x0000000000400545 <+9>:     add    %al,(%rax)
        0x0000000000400547 <+11>:    int3
        0x0000000000400548 <+12>:    rex.RB cld
        0x000000000040054a <+14>:    add    (%rax),%al
        0x000000000040054c <+16>:    add    %al,(%rax)
        0x000000000040054e <+18>:    mov    $0x0,%eax
        0x0000000000400553 <+23>:    pop    %rbp
        0x0000000000400554 <+24>:    retq
     End of assembler dump.
    
    Those breakpoint instructions are no longer installed in target memory
    they're stale in the code cache.  Easily confirmed by just disabling
    the code cache:
    
     (gdb) set code-cache off
     (gdb) disass main
     Dump of assembler code for function main:
        0x000000000040053c <+0>:     push   %rbp
        0x000000000040053d <+1>:     mov    %rsp,%rbp
     => 0x0000000000400540 <+4>:     movl   $0x1,-0x4(%rbp)
        0x0000000000400547 <+11>:    movl   $0x2,-0x4(%rbp)
        0x000000000040054e <+18>:    mov    $0x0,%eax
        0x0000000000400553 <+23>:    pop    %rbp
        0x0000000000400554 <+24>:    retq
     End of assembler dump.
    
    I stumbled upon this when writing a patch to infrun.c, that made
    handle_inferior_event & co fill in the cache before breakpoints were
    removed from the target.  Recall that wait_for_inferior flushes the
    dcache for every event.  So in that case, always-inserted mode was not
    necessary to trigger this.  It's just a convenient way to expose the
    issue.
    
    The dcache works at the raw memory level.  We need to update it
    whenever memory is written, no matter what kind of target memory
    object was originally passed down by the caller.  The issue is that
    the dcache update code isn't reached when a caller explicitly writes
    raw memory.  Breakpoint insertion/removal is one such case --
    mem-break.c uses target_write_read_memory/target_write_raw_memory.
    
    The fix is to move the dcache update code from memory_xfer_partial_1
    to raw_memory_xfer_partial so that it's always reachable.
    
    When we do that, we can actually simplify a series of things.
    memory_xfer_partial_1 no longer needs to handle writes for any kind of
    memory object, and therefore dcache_xfer_memory no longer needs to
    handle writes either.  So the latter (dcache_xfer_memory) and its
    callees can be simplified to only care about reads.  While we're
    touching dcache_xfer_memory's prototype, might as well rename it to
    reflect that fact that it only handles reads.
    
    Currently dcache_xfer_memory handles the case of a write failing.  The
    whole cache line is invalidated when that happens.  However,
    dcache_update, the sole mechanism for handling writes that will remain
    after the patch, does not presently handle that scenario.  That's a
    bug.  The patch makes it handle that, by passing down the
    to_xfer_partial result from the caller, so that it can better decide
    what to do itself.  While I was changing the function's prototype, I
    constified the myaddr parameter, getting rid of the need for the cast
    as seen in its existing caller.
    
    Tested on x86_64 Fedora 17, native and gdbserver.
    
    gdb/
    2014-03-05  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/16575
    	* dcache.c (dcache_poke_byte): Constify ptr parameter.  Return
    	void.  Update comment.
    	(dcache_xfer_memory): Delete.
    	(dcache_read_memory_partial): New, based on the read bits of
    	dcache_xfer_memory.
    	(dcache_update): Add status parameter.  Use ULONGEST for len, and
    	adjust.  Discard cache lines if the reason for the update was
    	error.
    	* dcache.h (dcache_xfer_memory): Delete declaration.
    	(dcache_read_memory_partial): New declaration.
    	(dcache_update): Update prototype.
    	* target.c (raw_memory_xfer_partial): Update the dcache here.
    	(memory_xfer_partial_1): Don't handle dcache writes here.
    
    gdb/testsuite/
    2014-03-05  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/16575
    	* gdb.base/breakpoint-shadow.exp (compare_disassembly): New
    	procedure.
    	(top level): Adjust to use it.  Add tests that exercise breakpoint
    	interaction with the code-cache.

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

Summary of changes:
 gdb/ChangeLog                                |   17 +++++
 gdb/dcache.c                                 |   88 ++++++++++----------------
 gdb/dcache.h                                 |   12 ++--
 gdb/target.c                                 |   49 ++++++---------
 gdb/testsuite/ChangeLog                      |    8 +++
 gdb/testsuite/gdb.base/breakpoint-shadow.exp |   38 +++++++++---
 6 files changed, 114 insertions(+), 98 deletions(-)


hooks/post-receive
-- 
gdb and binutils


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]