This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Possible bug with i386 watchpoints on several targets.
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- To: Pierre Muller <muller at cerbere dot u-strasbg dot fr>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 3 Dec 2001 13:09:50 +0200 (IST)
- Subject: Re: [RFC] Possible bug with i386 watchpoints on several targets.
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.