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

[Pierre Muller <muller@cerbere.u-strasbg.fr>]

At 20:48 30/11/2001 , Eli Zaretskii a écrit:
> > Date: Fri, 30 Nov 2001 17:04:58 +0100
> > From: Pierre Muller <muller@cerbere.u-strasbg.fr>
> > 
> > use the following command
> > (top-gdb) watch gdb_stdout
> > (top-gdb) r
> > Here you should get a stop due to the setting of gdb_stdout value.
> > (top-gdb) cont
> > you should now reach the debuggee command prompt,
> > simply quit.
> > (gdb) quit
> > and rerun the same executable without any watchpoint modification.
> > (top-gdb) run
> > if the bug that I found on both win32 (without i386_cleanup_deregs call)
> > and on current (a few days old) CVS for linux.
> > You won't get any stop on the second run.
>
>This has nothing to do with i386_cleanup_dregs or, indeed, the x86
>watchpoint support.  Type "maintenance show-debug-regs", and you will
>see that the watchpoint does trigger on the second run, but GDB
>ignores it.  It ignores the watchpoint because the old and the new
>values compare equal on the second run, so GDB thinks it's a false
>alarm.

No, sorry, but I don't agree here:
I retested with today CVS compiled for i386 linux .

   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.

   The reason is that on the second run
i386_linux_drset is not called again on the second run.
And its not called again because in i386_insert_aligned_watchpoint
the macros 
   I386_DR_LOW_SET_ADDR (i, addr);
   I386_DR_LOW_SET_CONTROL (dr_control_mirror);
are only called if the the debug register is used for the first time.

   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.

  Thus the enabling of the hardware watchpoint only 
does increment dr_ref_count[0] (line 334)
and no linux specifc functions are called.

   This is exactly the same behaviour as 
what I got before calling i386_cleanup_dregs 
for the cygwin target.


>The reason that hardware watchpoints are only considered to fire when
>the watched value changes is that hardware watchpoints are treated teh
>same as software watchpoints, and software watchpoints obviously
>cannot fire unless the watched value changes.
>
>I think it is fundamentally wrong to treat hardware and software
>watchpoints in a similar way.  I think hardware watchpoints should be
>treated like read and access watchpoints, not like software
>watchpoints.  If others (mainly Michael Snyder) agree, I will submit a
>patch that will make that change, and will also solve this particular
>problem raised by Pierre.

There may be different solutions to the problem above, but I
think that in any case, we need to reset dr_mirror and dr_ref_count 
array at each new start.

I believe that this would be enough to solve all current troubles.

PS: A propos unwanted output of the cygwin target
using debug registers, I find the same sort of unwanted output for the linux target,
probably due to the removal/reinsertion of hardware watchpoints
when loading dynamic libraries.




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