Fix target not halting when GDB jumps to a hardware breakpoint (#283)

* Fix target not halting when GDB jumps to a hardware breakpoint

This issue affects riscv-0.11. It is caused by OpenOCD manually
stepping over hardware breakpoints to resume or step after a halt.
This is not necessary as GDB should remove and add breakpoints as
required.

At the moment OpenOCD still steps over hardware watchpoints manually
as GDB needs to know which address triggered the watchpoint and
OpenOCD does not currently provide this information.

Tested on the freedom-e310-arty using the GDB regression suite.
There is one regression which is a corner case caused by a GDB bug.
If a breakpoint is set in GDB and then the executable file is
discarded, GDB reverts to its default information about address
sizes e.g. on the freedom-e310-arty, 0x20400000 becomes
0xffff20400000. As a result, GDB is unable to step over breakpoints
set before the executable was discarded.

* Fix style issues

* Revert "Fix style issues"

This reverts commit 43e7e4b.

* Revert "Fix target not halting when GDB jumps to a hardware breakpoint"

This reverts commit e2717e4.

* Don't step over breakpoints

Author: craigblackmore

src/target/riscv/riscv-011.c

@@ -1407,12 +1407,6 @@ static int strict_step(struct target *target, bool announce)
 
 	LOG_DEBUG("enter");
 
-	struct breakpoint *breakpoint = target->breakpoints;
-	while (breakpoint) {
-		riscv_remove_breakpoint(target, breakpoint);
-		breakpoint = breakpoint->next;
-	}
-
 	struct watchpoint *watchpoint = target->watchpoints;
 	while (watchpoint) {
 		riscv_remove_watchpoint(target, watchpoint);
@@ -1423,12 +1417,6 @@ static int strict_step(struct target *target, bool announce)
 	if (result != ERROR_OK)
 		return result;
 
-	breakpoint = target->breakpoints;
-	while (breakpoint) {
-		riscv_add_breakpoint(target, breakpoint);
-		breakpoint = breakpoint->next;
-	}
-
 	watchpoint = target->watchpoints;
 	while (watchpoint) {
 		riscv_add_watchpoint(target, watchpoint);