This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[pushed 0/3] dprintf and other simultaneous breakpoints/events - don't lose control
- From: Pedro Alves <palves at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Mon, 2 Jun 2014 23:32:38 +0100
- Subject: [pushed 0/3] dprintf and other simultaneous breakpoints/events - don't lose control
- Authentication-results: sourceware.org; auth=none
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