1. The standard way for debuggers to plant breakpoints in a program in RAM (whatever the processor instruction set) is to save the breakpointed instruction and replace it by a jump to the breakpoint handling code. After the breakpoint is triggered, the saved instruction is restored in its original place. If the interactive dialogue with the debugger during the breakpoint indicates that that the triggered breakpoint is to be removed, execution of the program can be resumed simply by jumping to the instruction that had been breakponted. However, if the dialogue with the debugger indicates that the breakpoint is to remain in place when execution of the program is resumed, implementation is more complicated. Execution of the saved instruction could be emulated, but this is difficult to do, ensuring all side effects such as condition code setting and exception triggering are performed correctly, as well as following all addressing modes, such as PC relative. It is much easier simply to execute the breakpointed instruction in place, but to plant another breakpoint on a subsequent instruction in the same basic block, usually the immediate successor to the original breakpoint, so that the breakpoint handler can regain control in order to replant the original breakpoint and remove the secondary one. This obviously has some challenges if the successor of the breakpointed instruction cannot be statically predicted, for instance if the breakpointed instruction is a conditional jump, but a common solution is simply to ban breakpointing such instructions.
Identify the critical races that exist with this scheme if the program is executed by multiple threads, possibly multiple cores or multiple processors. Use pseudo-code to illustrate how you would resolve these issues.