Nice explanation.
However, it didn't explain how the debugger can stop again at the breakpoint after the last step? The interrupt command has been replaced with the original command, so the process won't stop again..
However, it didn't explain how the debugger can stop again at the breakpoint after the last step? The interrupt command has been replaced with the original command, so the process won't stop again..
(You can engineer a deadlock in gdb due to this, e.g., on x64, by stepping over a SYSCALL instruction that reads from a pipe that's about to be filled by another thread. But you're unlikely to experience this in practice, as system calls are wrapped by a glibc function, and you'll probably be stepping over that rather than the instruction directly.)