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

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

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

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.