Re: [RFC] Possible bug with i386 watchpoints on several targets.

[Eli Zaretskii <eliz@is.elta.co.il>]

On Mon, 3 Dec 2001, Pierre Muller wrote:

>    Of course i386_stopped_data_address gets called, but if you 
> set a breakpoint on the end of this function and add the condition
> ' cond X ret != 0'
> Then you will clearly see that the behavior is wrong:
> only on the first run after setting a hardware watchpoint you will get
> a non zero return value for this watchpoint.

i386_stopped_data_address has no role when a write-data hardware 
watchpoint is hit, only when read or access watchpoints are hit.  At 
least that's my reading of the code and what I see tracing through 
execution.  See breakpoint.c:bpstat_stop_status, you will see there that 
hardware watchpoints and rwatch/awatch watchpoints are treated 
differently, and i386_stopped_data_address (called via the 
target_stopped_data_address macro) is only called for awatch/rwatch.

The important function for hardware watchpoints is watchpoint_check, not 
i386_stopped_data_address.

>    As the i386_cleanup_dregs is never called for linux target,
> the internal state of the dr_mirror and dr_ref_count
> is wrong on the second start.
> dr_mirror[0] still contains the hardware watchpoint address
> and dr_ref_count contains one.

Then please explain why does the DJGPP port exhibits the same behavior as 
the Linux port with the test program you posted.  go32-nat.c _does_ call 
i386_cleanup_dregs, but the watchpoint doesn't trigger on the second run.