[RFC] Possible bug with i386 watchpoints on several targets.
Eli Zaretskii
eliz@is.elta.co.il
Mon Dec 3 03:10:00 GMT 2001
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.
More information about the Gdb-patches
mailing list