And to complete the circle, the Unix way for one process to look at another’s program counter, ptrace(), works via signals. I recently had to implement a versi

And to complete the circle, the Unix way for one process to look at another’s program counter, ptrace(), works via signals. I recently had to implement a version of that behavior when writing a GDB stub for an embedded microkernel. The system in question originally had neither a debugger nor an equivalent of signals, or any other way for system calls (message sends and receives) to be interrupted – so the programs written for it naturally assumed they wouldn’t be, and didn’t have any code to retry interrupted operations. I could have gone through and changed those programs, but it would have been a lot of work and easy to get wrong. Instead, just as described in that link, I had the GDB stub set the PC to point back to the system call instruction, so it would be restarted after continuing the thread, and adjust the argument registers if necessary (e.g. if a combined message send+receive operation was interrupted after the send but before the receive, the arguments had to be changed to request only a receive). This was made more difficult by the fact that the microkernel originally threw away some of those register values, in the name of efficiency, assuming they wouldn’t be needed once the system call had started…