Re: [RFA- v2] Testcase for bug report 11531 and fix for Solaris

[Joel Brobecker <brobecker@adacore.com>]

> PS1: Once this macro is removed, I will submit a RFA for the complete
> removal of nm-i386-sol2.h.
> PS2: The code inside infrun.c ought to be changed as well. If it is
> now non-functional I propose to generate a compilation error if the
> macro is still defined, this way third party users will not be
> surprised that it does not work...

Since nm-i386-sol2.h was the last user of the CANNOT_STEP_HW_WATCHPOINTS
macro, we should just purge it entirely.  We cannot worry about third
parties that did not contribute their code (that includes people like me
who still has lots of uncontributed code in the AdaCore version of GDB).

> ChangeLog entry:
> 2010-04-24  Pierre Muller  <muller@ics.u-strasbg.fr>
> 
> 	* config/i386/nm-i386-sol2.h (CANNOT_STEP_HW_WATCHPOINTS):
> 	Remove macro.

As per the above, let's just purge the whole thing. You can, at your
convinience, just delete the line from the nm file and do the rest
of the purge separately, so do everything all in one patch.

> testsuite/ChangeLog entry:
> 
> 	PR breakpoints/11531.
> 	* testsuite/gdb.base/gdb11531.c: New file.
> 	* testsuite/gdb.base/gdb11531.exp: New file.


> +# If the breakpoint is at the same instruction as the 
> +# watchpoint value assignment
> +# you can fall into the problem of the stepping over the breakpoint
> +# location that can also trigger a watchpoint miss
> +# This is not the problem reported here.
> +# Thus we remove all breakpoints first.

Suggest a different wording:

# The breakpoint is probably at the instruction where the value being
# watched (myrec.x) gets updated.  This is the instruction where we
# expect to receive a watchpoint notification when we do the "stepi"
# below.  However, having the breakpoint at the same location as this
# intruction can possibly interfere with our testcase, as stepping
# over the breakpoint in order to get past it may incorrectly lead
# to the debugger missing the watchpoint hit.  This would be a bug
# in GDB, but this is not the bug that we are trying to test here.
# So, we remove all breakpoints first.

> +gdb_test "stepi" \
> +    "Old value = 0.*New value = 5.*" \
> +    "watchpoint variable triggers at next"

I would prefer that you would verify that the old value and new values
match exactly. The wildcard matching prevents that, so the test would
still pass even if the debugger printed that the new value was 51274793875.
It seems that the use of a wildcard here is just a cheap way of matching
a new-line sequence - the typical way of matching new-lines, I've found,
is to use "\[\r\n\]+". It's been helpful to define a variable with a short
name that contains that regexp and use that variable, rather than repeat
manually the new-line regexp...

> +gdb_test "start" "" "restart"
> +
> +gdb_test "next" "Old value = 0.*New value = 5.*" "watchpoint triggers after
> second start"

Can you explain the purpose of this part of the testcase. Again, the use
of the start command in a gdb_test does not work with some configurations.

-- 
Joel