OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

PR breakpoints/11531. 

* config/i386/nm-i386sol2.h (CANNOT_STEP_HW_WATCHPOINTS): Remove
	macro definition and related comment.
	* infrun.c (CANNOT_STEP_HW_WATCHPOINTS): Remove macro.
	(resume): Remove code and comment related to this macro.

doc ChangeLog entry:
	* gdbint.texinfo (CANNOT_STEP_HW_WATCHPOINTS): Remove explanation
	of macro deleted from GDB code.
This commit is contained in:
Pierre Muller 2010-04-26 12:01:44 +00:00
parent 72f6eb52ad
commit b7da9e9f5f
5 changed files with 13 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
gdb/ChangeLog
View File

@ -1,3 +1,11 @@
2010-04-26 Pierre Muller <muller@ics.u-strasbg.fr>
PR breakpoints/11531.
* config/i386/nm-i386sol2.h (CANNOT_STEP_HW_WATCHPOINTS): Remove
macro definition and related comment.
* infrun.c (CANNOT_STEP_HW_WATCHPOINTS): Remove macro.
(resume): Remove code and comment related to this macro.
2010-04-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* cp-namespace.c (cp_lookup_symbol_in_namespace): Fix alloca size.

10
gdb/config/i386/nm-i386sol2.h
View File

@ -19,14 +19,4 @@
#ifdef NEW_PROC_API /* Solaris 6 and above can do HW watchpoints */
/* Solaris x86 2.6 and 2.7 targets have a kernel bug when stepping
over an instruction that causes a page fault without triggering
a hardware watchpoint. The kernel properly notices that it shouldn't
stop, because the hardware watchpoint is not triggered, but it forgets
the step request and continues the program normally.
Work around the problem by removing hardware watchpoints if a step is
requested, GDB will check for a hardware watchpoint trigger after the
step anyway. */
#define CANNOT_STEP_HW_WATCHPOINTS
#endif /* NEW_PROC_API */

5
gdb/doc/ChangeLog
View File

@ -1,3 +1,8 @@
2010-04-26 Pierre Muller <muller@ics.u-strasbg.fr>
* gdbint.texinfo (CANNOT_STEP_HW_WATCHPOINTS): Remove explanation
of macro deleted from GDB code.
2010-04-24 Pedro Alves <pedro@codesourcery.com>
* gdb.texinfo (Commands to specify files): Describe what how GDB

5
gdb/doc/gdbint.texinfo
View File

@ -781,11 +781,6 @@ inferior after a watchpoint has been hit. This is usually set
when watchpoints trigger at the instruction following an interesting
read or write.
@findex CANNOT_STEP_HW_WATCHPOINTS
@item CANNOT_STEP_HW_WATCHPOINTS
If this is defined to a non-zero value, @value{GDBN} will remove all
watchpoints before stepping the inferior.
@findex STOPPED_BY_WATCHPOINT
@item STOPPED_BY_WATCHPOINT (@var{wait_status})
Return non-zero if stopped by a watchpoint. @var{wait_status} is of

22
gdb/infrun.c
View File

@ -179,16 +179,6 @@ show_debug_infrun (struct ui_file *file, int from_tty,
#endif
/* Convert the #defines into values. This is temporary until wfi control
flow is completely sorted out. */
#ifndef CANNOT_STEP_HW_WATCHPOINTS
#define CANNOT_STEP_HW_WATCHPOINTS 0
#else
#undef CANNOT_STEP_HW_WATCHPOINTS
#define CANNOT_STEP_HW_WATCHPOINTS 1
#endif
/* Tables of how to react to signals; the user sets them. */
static unsigned char *signal_stop;
@ -1484,18 +1474,6 @@ resume (int step, enum target_signal sig)
"trap_expected=%d\n",
step, sig, tp->trap_expected);
/* Some targets (e.g. Solaris x86) have a kernel bug when stepping
over an instruction that causes a page fault without triggering
a hardware watchpoint. The kernel properly notices that it shouldn't
stop, because the hardware watchpoint is not triggered, but it forgets
the step request and continues the program normally.
Work around the problem by removing hardware watchpoints if a step is
requested, GDB will check for a hardware watchpoint trigger after the
step anyway. */
if (CANNOT_STEP_HW_WATCHPOINTS && step)
remove_hw_watchpoints ();
/* Normally, by the time we reach `resume', the breakpoints are either
removed or inserted, as appropriate. The exception is if we're sitting
at a permanent breakpoint; we need to step over it, but permanent