4 ms·

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 wit

• hderms 10y ago
  Could presumably replace the following instructions with int 3 and basically swap it back without showing the interactive user anything
  • ubershmekel 10y ago
    "the following instructions" may be a bit tricky. E.g. if the instruction jumps to itself.
    • hderms 10y ago
      Very true, you can tell I'm not an assembly guy
• dimfeld 10y ago
  Usually the debugger just replaces the breakpoint instruction with the original byte, then resumes execution in a single-step mode that causes the CPU to just execute a single instruction before firing another interrupt. After that, the debugger sets the breakpoint again and resumes normal execution.
  • to3m 10y ago
    When single-stepping, it's necessary to step only one thread, to ensure that other threads don't skip the (temporarily) disabled breakpoint. There's a paper here that discusses one solution to the problems this causes: http://www.bmrtech.com/uploadfile/image/whitepaper/mentorpaper_multcore_db.pdf http://www.bmrtech.com/uploadfile/image/whitepaper/mentorpap... (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.)