Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro

[Pedro Alves <pedro@codesourcery.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