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

[Pierre Muller <muller at cerbere dot u-strasbg dot fr>]

At 12:09 03/12/2001 , Eli Zaretskii a écrit:

>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.

That is not totally true, because
i386_stopped_by_data_address is also used in STOPPED_BY_WATCHPOINT
macro, which explains why I see that the code uses that function for
normal watchpoints.
But I agree that its called but not really used.

>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.


   I now also managed to compile gdb for djgpp
and understood why I do get different results for cygwin and djgpp
targets:
    do to DLL loadings, the watchpoints are removed and reinserted at program startup
(same goes for linux programs that use shared libs)
and thus the correct starting state of the watchpoints are 
loaded again.

   On the contrary, this does never occur in djgpp target,
so that this target keeps the wrong value of the end of the previous run.

   So I finally agree with Eli to say that there a two problems here.
One relative to the fact that the watchpoint values are not correctly resetted
when the program restarts. But also a second problem if 
i386_cleanup_dregs is not called, because the target is not supposed to reuse
the debug register values of the previous run, and with the current implementation
not calling the i386_cleanup_dregs will result in
not explicitly setting the values of the debug registers
in the next run...



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99