[commit] Fix watchpoint-solib.exp with software watchpoints

[Pedro Alves <pedro at codesourcery dot com>]

[Another spurious SIGTRAP that somehow appeared to me to be
 non-stop related ...]

watchpoint-solib.exp is failing currently when ran against gdbserver:

(gdb) FAIL: gdb.base/watchpoint-solib.exp: rerun to main

In fact, this is not gdbserver/remote specific, but, related
to software watchpoints.  This patchlet makes the FAIL trigger
against native x86_64-linux as well:

Index: src/gdb/testsuite/gdb.base/watchpoint-solib.exp
===================================================================
--- src.orig/gdb/testsuite/gdb.base/watchpoint-solib.exp        2009-03-17 23:58:59.000000000 +0000
+++ src/gdb/testsuite/gdb.base/watchpoint-solib.exp     2009-03-18 00:06:33.000000000 +0000
@@ -70,9 +70,9 @@ if [target_info exists gdb_stub] {
 runto_main

 # Disable hardware watchpoints if necessary.
-if [target_info exists gdb,no_hardware_watchpoints] {
+#if [target_info exists gdb,no_hardware_watchpoints] {
     gdb_test "set can-use-hw-watchpoints 0" "" ""
-}
+#}

Here's what happens, with "set debug infrun 1" on:

  (gdb) PASS: gdb.base/watchpoint-solib.exp: continue to watchpoint hit
  run
  The program being debugged has been started already.
  Start it from the beginning? (y or n) y
  Starting program: /home/pedro/gdb/gdbserver_nonstop/build/gdb/testsuite/gdb.base/watchpoint-solib
  Error in re-setting breakpoint 3: No symbol "g" in current context.
  Error in re-setting breakpoint 3: No symbol "g" in current context.

Here, we lost the watchpoint's locations, since the shared library that
held "g" was unloaded.  This happens with hardware watchpoints as well.  For
the test's purpose, this is fine so far.

  infrun: proceed (addr=0xffffffffffffffff, signal=0, step=0)
  infrun: resume (step=1, signal=0), trap_expected=0

Yet, here, the target was single-stepped for no apparent reason.

  infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
  infrun: target_wait (-1, status) =
  infrun:   30418 [process 30418],
  infrun:   status->kind = stopped, signal = SIGTRAP
  infrun: infwait_normal_state
  infrun: TARGET_WAITKIND_STOPPED
  infrun: stop_pc = 0x2aaaaaaaba63
  infrun: random signal 5
  Program received signal SIGTRAP, Trace/breakpoint trap.
  infrun: stop_stepping
  0x00002aaaaaaaba63 in ?? () from /lib64/ld-linux-x86-64.so.2
  0x00002aaaaaaaba63 <free@plt+27>:       callq  0x2aaaaaaacfe0 <free@plt+5528>

So when the single-step finishes, GDB considers the SIGTRAP a
spurious signal.

What happened was that bpstat_should_step, noticing that there's an
enabled software watchpoint listed, returns true, even through there's no
location associated with that watchpoint.  Later, when the single-step
finishes, bpstat_stop_status walks through the location list, and doesn't
find any explanation for the stop.

Here's a simple fix: make sure bpstat_should_step returns true only if
there's a location associated with the software watchpoint.

Tested on x86_64-linux, and checked in.

-- 
Pedro Alves

2009-03-18  Pedro Alves  <pedro@codesourcery.com>

	* breakpoint.c (bpstat_should_step): Only consider software
	watchpoints that have a location.

---
 gdb/breakpoint.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: src/gdb/breakpoint.c
===================================================================
--- src.orig/gdb/breakpoint.c	2009-03-17 23:55:04.000000000 +0000
+++ src/gdb/breakpoint.c	2009-03-17 23:57:19.000000000 +0000
@@ -3304,7 +3304,7 @@ bpstat_should_step (void)
 {
   struct breakpoint *b;
   ALL_BREAKPOINTS (b)
-    if (breakpoint_enabled (b) && b->type == bp_watchpoint)
+    if (breakpoint_enabled (b) && b->type == bp_watchpoint && b->loc != NULL)
       return 1;
   return 0;
 }