This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de, gdb at sourceware dot org, 'Pieter Maljaars' <pieter dot maljaars at altenpts dot nl>, "'Joseph S. Myers'" <joseph at codesourcery dot com>, 'Pedro Alves' <pedro at codesourcery dot com>
- Date: Thu, 22 Apr 2010 19:59:56 -0400
- Subject: Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro
- References: <001501cad820$36771f50$a3655df0$@muller@ics-cnrs.unistra.fr> <20100422135635.GE13204@adacore.com> <003101cae232$e2564ff0$a702efd0$@muller@ics-cnrs.unistra.fr>
> setting a watchpoint on myrec.x and
> stepping should expose the bug if you
> remove the CANNOT_STEP_HW_WATCHPOINT from nm-i386sol2.h
Looks like a different bug is now occurring:
(gdb) start
Temporary breakpoint 1 at 0x805067a: file foo.c, line 13.
Starting program: [...]/foo
Temporary breakpoint 1, main () at foo.c:13
13 myrec.x = 5;
(gdb) print myrec.x
$1 = 0
(gdb) watch myrec.x
Hardware watchpoint 2: myrec.x
(gdb) s
14 myrec.y = 3.4;
In other words, the program did not "continue" during the step, but
the watchpoint did not trigger either. Later on, during the same run:
(gdb) s
16 myrec.x = 78;
(gdb) s
17 return myrec.x;
(no trigger of the watchpoint either).
However, when doing a "continue" instead of a step, we do get the
watchpoint hit:
(gdb) start
Temporary breakpoint 1 at 0x805067a: file foo.c, line 13.
Starting program: [...]/foo
Temporary breakpoint 1, main () at foo.c:13
13 myrec.x = 5;
(gdb) watch myrec.x
Hardware watchpoint 2: myrec.x
(gdb) cont
Continuing.
Hardware watchpoint 2: myrec.x
Old value = 0
New value = 5
main () at foo.c:14
14 myrec.y = 3.4;
I compared the behavior with the same program, but on x86-linux.
We get the expected behavior:
(gdb) watch myrec.x
Hardware watchpoint 2: myrec.x
(gdb) s
Hardware watchpoint 2: myrec.x
Old value = 0
New value = 5
main () at foo.c:14
14 myrec.y = 3.4;
Looking at the infrun debug output:
(gdb) set debug infrun 1
(gdb) s
infrun: clear_proceed_status_thread (LWP 1)
infrun: proceed (addr=0xffffffff, signal=144, step=1)
infrun: resume (step=1, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun: 3497 [LWP 1],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8050684
infrun: stepped to a different line
infrun: stop_stepping
14 myrec.y = 3.4;
So we failed to notice that the watchpoint triggered - we should probably
look in the area of procfs_stopped_by_watchpoint. Maybe another kernel
issue???
If I use the "continue" command instead of a step, the infrun debug
output looks like this:
(gdb) cont
Continuing.
infrun: clear_proceed_status_thread (LWP 1)
infrun: proceed (addr=0xffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun: 3524 [LWP 1],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8050684
infrun: stopped by watchpoint <<<<<---------
infrun: (no data address available)
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_stepping
Hardware watchpoint 2: myrec.x
Old value = 0
New value = 5
main () at foo.c:14
14 myrec.y = 3.4;
I ran watchpoint.exp alone and the testcase passes without any problem.
One last thing: It does not make any difference whether the
CANNOT_STEP_HW_WATCHPOINT macro is defined or not. So, I think that,
starting with version 2.8, it's safe to not have it defined.
--
Joel