[pushed 0/3] dprintf and other simultaneous breakpoints/events - don't lose control

[Pedro Alves <palves at redhat dot com>]

While reviewing / working on Joel's patch for PR 17000
(https://sourceware.org/ml/gdb-patches/2014-05/msg00761.html), I
played with stepping over a dprintf with software single-stepping.
Fixing that made me re-stumble on the issue that when a _regular_
breakpoint is set at the same address as a dprintf, GDB also loses
control.  There's a wider issue to handle here (PR 15180), which I
know Hui has a proposed fix, but while that will take a while to
digest and see through to mainline, and with 7.8 around the corner,
it's best if GDB at least doesn't lose control of the inferior.  In
any case, I think that even with the proposed fix for 15180, we'll
still need this against un-fixed gdbservers.

Tested on x86_64 Fedora 20, native and gdbserver.

Pedro Alves (3):
  gdbserver: on GDB breakpoint reinsertion, also delete the breakpoint's
    commands.
  dprintf-style agent can't explain a trap.
  Installing a breakpoint on top of a dprintf makes GDB lose control.

 gdb/ChangeLog                                   | 11 +++++
 gdb/gdbserver/ChangeLog                         | 12 +++++
 gdb/testsuite/ChangeLog                         |  5 ++
 gdb/breakpoint.c                                | 38 ++++++++++++--
 gdb/gdbserver/ax.c                              | 10 ++++
 gdb/gdbserver/ax.h                              |  3 ++
 gdb/gdbserver/mem-break.c                       | 43 +++++++++++++---
 gdb/gdbserver/mem-break.h                       |  5 +-
 gdb/gdbserver/server.c                          |  2 +-
 gdb/testsuite/gdb.base/dprintf-bp-same-addr.c   | 28 +++++++++++
 gdb/testsuite/gdb.base/dprintf-bp-same-addr.exp | 66 +++++++++++++++++++++++++
 11 files changed, 210 insertions(+), 13 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/dprintf-bp-same-addr.c
 create mode 100644 gdb/testsuite/gdb.base/dprintf-bp-same-addr.exp

-- 
1.9.0