Bug 16575 - stale breakpoint instructions in the code cache
Summary: stale breakpoint instructions in the code cache
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.7
: P2 normal
Target Milestone: 7.8
Assignee: Pedro Alves
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-13 15:01 UTC by Pedro Alves
Modified: 2014-05-05 21:54 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro Alves 2014-02-13 15:01:27 UTC
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.:

 (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.
Comment 1 Pedro Alves 2014-02-13 15:01:53 UTC
I have a fix.
Comment 2 cvs-commit@gcc.gnu.org 2014-03-05 14:30:53 UTC
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  0f26cec1fd54c0428fda6c93c0375400e1bca738 (commit)
      from  4b95cf5c0c75d6efc1b2f96af72317aecca079f1 (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=0f26cec1fd54c0428fda6c93c0375400e1bca738

commit 0f26cec1fd54c0428fda6c93c0375400e1bca738
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, and make it follow the
    new target_xfer_status/xfered_len style.  This made me notice that
    dcache_xfer_memory loses the real error status if a memory read fails:
    we could have failed to read due to TARGET_XFER_E_UNAVAILABLE, for
    instance, but we always return TARGET_XFER_E_IO, hence the FIXME note.
    I felt that fixing that fell out of the scope of this patch.
    
    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
    target_xfer_status status 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                                 |  100 +++++++++++--------------
 gdb/dcache.h                                 |   15 ++--
 gdb/target.c                                 |   53 +++++---------
 gdb/testsuite/ChangeLog                      |    8 ++
 gdb/testsuite/gdb.base/breakpoint-shadow.exp |   38 ++++++++--
 6 files changed, 127 insertions(+), 104 deletions(-)
Comment 3 cvs-commit@gcc.gnu.org 2014-03-05 15:05:57 UTC
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(-)
Comment 4 Pedro Alves 2014-03-05 15:18:23 UTC
Fixed, 7.8 and 7.7.1.
Comment 5 cvs-commit@gcc.gnu.org 2014-05-05 21:54:13 UTC
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 annotated tag, gdb-7.7.1-release has been created
        at  af2cd04ccdd7631f4009b2aef5c8402b97d732e6 (tag)
   tagging  4bd8fc3a1362970d9800a263987af8093798338b (commit)
  replaces  gdb-7.7-release
 tagged by  Joel Brobecker
        on  Mon May 5 14:53:19 2014 -0700

- Log -----------------------------------------------------------------
GDB 7.7.1 Release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEABECAAYFAlNoCE8ACgkQku2wS/8yXPMbgQCgiCmLYGN3tjnqEEc0Y0i4iCHj
RN8AnRgphFx5RnfZ5TSUHgC6mVHel7sC
=xfEO
-----END PGP SIGNATURE-----

Eli Zaretskii (1):
      PR gdb/14018 -- avoid "PC register not available" errors.

GDB Administrator (88):
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in

Jan Kratochvil (3):
      Fix Python stack corruption
      PR gdb/16626
      PR gdb/16626

Joel Brobecker (3):
      Document the GDB 7.7 release in gdb/ChangeLog
      Bump GDB version number to 7.7.0.DATE-cvs.
      Set GDB version number to 7.7.1.

Nick Clifton (1):
      Following up on Tom's suggestion I am checking in a patch to replace the various

Pedro Alves (3):
      Make sure we don't resume the stepped thread by accident.
      PR gdb/16575: stale breakpoint instructions in the code cache
      AIX 32-bit core loading, high section addresses.

Pierre Langlois (1):
      Erroneous backtrace on AVR.

Rainer Orth (1):
      PR build/16550

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