Re: Question about solaris CANNOT_STEP_HW_WATCHPOINTS macro

[Joel Brobecker <brobecker@adacore.com>]

> 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