public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control
@ 2014-05-30 16:09 palves at redhat dot com
2014-05-30 16:11 ` [Bug breakpoints/17000] " palves at redhat dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: palves at redhat dot com @ 2014-05-30 16:09 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
Bug ID: 17000
Summary: sss breakpoint on top of a regular breakpoint; gdb
loses control
Product: gdb
Version: 7.7
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: palves at redhat dot com
This was first reported as a regression caused by the fix for
bug 7143. See discussion starting at:
https://sourceware.org/bugzilla/show_bug.cgi?id=7143#c12
On software single-step targets, if another breakpoint happens to be inserted
where a single-step breakpoint is also inserted, and gdb removes the
single-step breakpoint, while intenting to leave the other breakpoint inserted,
GDB actually really removes the breakpoint from the target, while it thinks it
hasn't, leading to all sort of nasty issues related to the breakpoint being
missed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug breakpoints/17000] sss breakpoint on top of a regular breakpoint; gdb loses control
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
@ 2014-05-30 16:11 ` palves at redhat dot com
2014-05-30 16:17 ` [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location palves at redhat dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: palves at redhat dot com @ 2014-05-30 16:11 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|gdb |breakpoints
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
2014-05-30 16:11 ` [Bug breakpoints/17000] " palves at redhat dot com
@ 2014-05-30 16:17 ` palves at redhat dot com
2014-05-30 16:22 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: palves at redhat dot com @ 2014-05-30 16:17 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|sss breakpoint on top of a |user breakpoint not
|regular breakpoint; gdb |inserted if
|loses control |software-single-step at
| |same location
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
2014-05-30 16:11 ` [Bug breakpoints/17000] " palves at redhat dot com
2014-05-30 16:17 ` [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location palves at redhat dot com
@ 2014-05-30 16:22 ` cvs-commit at gcc dot gnu.org
2014-06-03 11:50 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-05-30 16:22 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.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 9ba6657a6b81a02dca9071ec14cbcef970f0ca07 (commit)
from 522c09bf63a4b235e6fde07a5e389f2a533cfe0f (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=9ba6657a6b81a02dca9071ec14cbcef970f0ca07
commit 9ba6657a6b81a02dca9071ec14cbcef970f0ca07
Author: Pedro Alves <palves@redhat.com>
Date: Fri May 30 17:21:02 2014 +0100
PR breakpoints/17000: user breakpoint not inserted if software-single-step
at same location - test
GDB gets confused when removing a software single-step breakpoint that
is at the same address as another breakpoint. Add a kfailed test.
gdb/testsuite/
2014-05-30 Pedro Alves <palves@redhat.com>
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp.c: New file.
* gdb.base/sss-bp-on-user-bp.exp: New file.
-----------------------------------------------------------------------
Summary of changes:
gdb/testsuite/ChangeLog | 6 +++
gdb/testsuite/gdb.base/sss-bp-on-user-bp.c | 30 +++++++++++++++
gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp | 52 ++++++++++++++++++++++++++
3 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp.c
create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
` (2 preceding siblings ...)
2014-05-30 16:22 ` cvs-commit at gcc dot gnu.org
@ 2014-06-03 11:50 ` cvs-commit at gcc dot gnu.org
2014-06-03 16:44 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-06-03 11:50 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.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 835c559fd59d4ebb3b04d046c1f9f36183db0fe6 (commit)
from 06eb158633faa8746dd39f19ce784448bb7ece00 (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=835c559fd59d4ebb3b04d046c1f9f36183db0fe6
commit 835c559fd59d4ebb3b04d046c1f9f36183db0fe6
Author: Pedro Alves <palves@redhat.com>
Date: Tue Jun 3 12:46:46 2014 +0100
PR breakpoints/17000: user breakpoint not inserted if software-single-step
at same location - test
GDB gets confused when removing a software single-step breakpoint that
is at the same address as another breakpoint. Add another kfailed
test.
gdb/testsuite/
2014-06-03 Pedro Alves <palves@redhat.com>
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp-2.c: New file.
* gdb.base/sss-bp-on-user-bp-2.exp: New file.
-----------------------------------------------------------------------
Summary of changes:
gdb/testsuite/ChangeLog | 6 ++
gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c | 29 ++++++
gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp | 109 ++++++++++++++++++++++++
3 files changed, 144 insertions(+), 0 deletions(-)
create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c
create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
` (3 preceding siblings ...)
2014-06-03 11:50 ` cvs-commit at gcc dot gnu.org
@ 2014-06-03 16:44 ` cvs-commit at gcc dot gnu.org
2014-06-03 16:52 ` palves at redhat dot com
2014-06-04 12:59 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-06-03 16:44 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.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 ef370185fcf955b1273c2c6bcbe0b406ec1cbd83 (commit)
from c32abae8456a2cb959862626b5ff9ebdd1543514 (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=ef370185fcf955b1273c2c6bcbe0b406ec1cbd83
commit ef370185fcf955b1273c2c6bcbe0b406ec1cbd83
Author: Joel Brobecker <brobecker@adacore.com>
Date: Tue Jun 3 17:42:19 2014 +0100
User breakpoint ignored if software-single-step at same location
with the following code...
12 Nested; -- break #1
13 return I; -- break #2
14 end;
(line 12 is a call to function Nested)
... we have noticed the following errorneous behavior on ppc-aix,
where, after having inserted a breakpoint at line 12 and line 13,
and continuing from the breakpoint at line 12, the program never
stops at line 13, running away until the program terminates:
% gdb -q func
(gdb) b func.adb:12
Breakpoint 1 at 0x10000a24: file func.adb, line 12.
(gdb) b func.adb:13
Breakpoint 2 at 0x10000a28: file func.adb, line 13.
(gdb) run
Starting program: /[...]/func
Breakpoint 1, func () at func.adb:12
12 Nested; -- break #1
(gdb) c
Continuing.
[Inferior 1 (process 4128872) exited with code 02]
When resuming from the first breakpoint, GDB first tries to step out
of that first breakpoint. We rely on software single-stepping on this
platform, and it just so happens that the address of the first
software single-step breakpoint is the same as the user's breakpoint
#2 (0x10000a28). So, with infrun and target traces turned on (but
uninteresting traces snip'ed off), the "continue" operation looks like
this:
(gdb) c
### First, we insert the user breakpoints (the second one is an
internal
### breakpoint on __pthread_init). The first user breakpoint is not
### inserted as we need to step out of it first.
target_insert_breakpoint (0x0000000010000a28, xxx) = 0
target_insert_breakpoint (0x00000000d03f3800, xxx) = 0
### Then we proceed with the step-out-of-breakpoint...
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
thread [process 15335610] at 0x10000a24
### That's when we insert the SSS breakpoints...
target_insert_breakpoint (0x0000000010000a28, xxx) = 0
target_insert_breakpoint (0x00000000100009ac, xxx) = 0
### ... then let the inferior resume...
target_resume (15335610, continue, 0)
infrun: wait_for_inferior ()
target_wait (-1, status, options={}) = 15335610, status->kind =
stopped, signal = GDB_SIGNAL_TRAP
infrun: target_wait (-1, status) =
infrun: 15335610 [process 15335610],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x100009ac
### At this point, we stopped at the second SSS breakpoint...
target_stopped_by_watchpoint () = 0
### We remove the SSS breakpoints...
target_remove_breakpoint (0x0000000010000a28, xxx) = 0
target_remove_breakpoint (0x00000000100009ac, xxx) = 0
target_stopped_by_watchpoint () = 0
### We find that we're not done, so we resume....
infrun: no stepping, continue
### And thus insert the user breakpoints again, except we're not
### inserting the second breakpoint?!?
target_insert_breakpoint (0x0000000010000a24, xxx) = 0
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current
thread [process 15335610] at 0x100009ac
target_resume (-1, continue, 0)
infrun: prepare_to_wait
target_wait (-1, status, options={}) = 15335610, status->kind =
exited, status = 2
What happens is that the removal of the software single-step
breakpoints effectively removed the breakpoint instruction from
inferior memory. But because such breakpoints are inserted directly
as raw breakpoints rather than through the normal chain of
breakpoints, we fail to notice that one of the user breakpoints points
to the same address and that this user breakpoint is therefore
effectively un-inserted. When resuming after the single-step, GDB
thinks that the user breakpoint is still inserted and therefore does
not need to insert it again.
This patch teaches the insert and remove routines of both regular and
raw breakpoints to be aware of each other. Special care needs to be
applied in case the target supports evaluation of breakpoint
conditions or commands.
gdb/ChangeLog:
PR breakpoints/17000
* breakpoint.c (find_non_raw_software_breakpoint_inserted_here):
New function, extracted from software_breakpoint_inserted_here_p.
(software_breakpoint_inserted_here_p): Replace factored out code
by call to find_non_raw_software_breakpoint_inserted_here.
(bp_target_info_copy_insertion_state): New function.
(bkpt_insert_location): Handle the case of a single-step
breakpoint already inserted at the same address.
(bkpt_remove_location): Handle the case of a single-step
breakpoint still inserted at the same address.
(deprecated_insert_raw_breakpoint): Handle the case of non-raw
breakpoint already inserted at the same address.
(deprecated_remove_raw_breakpoint): Handle the case of a
non-raw breakpoint still inserted at the same address.
(find_single_step_breakpoint): New function, extracted from
single_step_breakpoint_inserted_here_p.
(find_single_step_breakpoint): New function,
factored out from single_step_breakpoint_inserted_here_p.
(single_step_breakpoint_inserted_here_p): Reimplement.
gdb/testsuite/ChangeLog:
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp.exp: Remove kfail.
* gdb.base/sss-bp-on-user-bp-2.exp: Remove kfail.
Tested on ppc-aix with AdaCore's testsuite. Tested on x86_64-linux,
(native and gdbserver) with the official testsuite. Also tested on
x86_64-linux through Pedro's branch enabling software single-stepping
on that platform (native and gdbserver).
-----------------------------------------------------------------------
Summary of changes:
gdb/ChangeLog | 23 ++++
gdb/breakpoint.c | 141 +++++++++++++++++++++---
gdb/testsuite/ChangeLog | 7 +
gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp | 1 -
gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp | 3 +-
5 files changed, 155 insertions(+), 20 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
` (4 preceding siblings ...)
2014-06-03 16:44 ` cvs-commit at gcc dot gnu.org
@ 2014-06-03 16:52 ` palves at redhat dot com
2014-06-04 12:59 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: palves at redhat dot com @ 2014-06-03 16:52 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |7.8
--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
Fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
` (5 preceding siblings ...)
2014-06-03 16:52 ` palves at redhat dot com
@ 2014-06-04 12:59 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-06-04 12:59 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=17000
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.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 03388bb71c1a1d1c613bb963f3d9287cfd100138 (commit)
from ac21917f6bef764c73323c8117d293b5f6c70228 (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=03388bb71c1a1d1c613bb963f3d9287cfd100138
commit 03388bb71c1a1d1c613bb963f3d9287cfd100138
Author: Yao Qi <yao@codesourcery.com>
Date: Wed Jun 4 13:03:19 2014 +0800
Tweak sss-bp-on-user-bp.exp
sss-bp-on-user-bp.c has an assumption that write to integer can be
compiled to a single instruction, which isn't true on some arch, such
as arm. This test requires setting two breakpoints on two consecutive
instructions, so this patch is to get the address of the next
instruction via disassemble and set the 2nd breakpoint there. This
approach is portable.
This patch fixes the fails in sss-bp-on-user-bp.exp on arm-none-abi
target. There is no change in x86 test results. I also revert the
patch to PR breakpoints/17000, and verified that the patched
sss-bp-on-user-bp.exp still trigger the fail on
x86-with-software-single-step.
gdb/testsuite:
2014-06-04 Yao Qi <yao@codesourcery.com>
* gdb.base/sss-bp-on-user-bp.c (main): Remove comments.
* gdb.base/sss-bp-on-user-bp.exp: Don't set breakpoint on
"set bar break here". Get the next instruction address and
set breakpoint there. Remove "bar break" from the regexp
patterns.
-----------------------------------------------------------------------
Summary of changes:
gdb/testsuite/gdb.base/sss-bp-on-user-bp.c | 4 ++--
gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp | 20 +++++++++++++++++---
2 files changed, 19 insertions(+), 5 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-06-04 12:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-30 16:09 [Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control palves at redhat dot com
2014-05-30 16:11 ` [Bug breakpoints/17000] " palves at redhat dot com
2014-05-30 16:17 ` [Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location palves at redhat dot com
2014-05-30 16:22 ` cvs-commit at gcc dot gnu.org
2014-06-03 11:50 ` cvs-commit at gcc dot gnu.org
2014-06-03 16:44 ` cvs-commit at gcc dot gnu.org
2014-06-03 16:52 ` palves at redhat dot com
2014-06-04 12:59 ` cvs-commit at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).