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: Pedro Alves <pedro at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>, 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>
- Date: Fri, 23 Apr 2010 01:56:03 +0100
- Subject: Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro
- References: <001501cad820$36771f50$a3655df0$@muller@ics-cnrs.unistra.fr> <003101cae232$e2564ff0$a702efd0$@muller@ics-cnrs.unistra.fr> <20100422235956.GG13204@adacore.com>
On Friday 23 April 2010 00:59:56, Joel Brobecker wrote:
> > 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:
...
> 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???
I think older GDBs handled this because they always checked for
watchpoint hits at every SIGTRAP. Notice the comment in infrun.c:
> /* 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. */
^^^^^^^^^^^
That underlined part of the comment is no longer true nowadays.
See PR9633 <http://sourceware.org/bugzilla/show_bug.cgi?id=9633>, which
points at some other target relying on it.
> 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.
Do we still care for <= 2.7 at this point? (and before someone
spontaneously says "yes"; does GDB still work okay on such old
Solaris systems?)
--
Pedro Alves