If you have two inferiors (or more), set watchpoints in one of the
inferiors, and then that inferior exits, until you manually delete the
watchpoint (or something forces a breakpoint re-set), you can't resume
the other inferior.
This is exercised by the test added by this commit. Without the GDB
fix, this test fails like this:
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=kill: continue to marker in inferior 1
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=detach: continue to marker in inferior 1
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=exit: continue to marker in inferior 1
and gdb.log shows (in all three cases):
(gdb) continue
Continuing.
Warning:
Could not insert hardware watchpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
(gdb) FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=kill: continue to marker in inferior 1
The problem is that GDB doesn't forget about the locations of
watchpoints set in the inferior that is now dead. When we try to
continue the inferior that is still alive, we reach
insert_breakpoint_locations, which has the the loop that triggers the
error:
/* If we failed to insert all locations of a watchpoint, remove
them, as half-inserted watchpoint is of limited use. */
That loop finds locations that are not marked inserted, but which
according to should_be_inserted should have been inserted, and so
errors out.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoint_init_inferior): Discard watchpoint
locations.
* infcmd.c (detach_command): Call breakpoint_init_inferior.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* gdb.multi/watchpoint-multi-exit.c: New file.
* gdb.multi/watchpoint-multi-exit.exp: New file.
6300088845