Ytdyklly

As you may know, we can use GDB and set breakpoints on our code to pause execution for debugging.

My questions is, how does GDB pause a process and let you view the content of registers using i r for example. Aren't those register being used by other OS processes constantly? how do they not get overwritten?

Is it only a snapshot of the content and not live data?

It varies slightly with the architecture, but the important points apply nearly universally:

• Interrupt servicing causes the CPU state (including registers) to be saved to memory before running the ISR, and restored as the ISR exits.




• If an interrupt service routine swaps the content of the memory location where those registers are saved, it can perform a context switch. Every thread has a memory region where its registers are saved when the thread isn't running.




• The context switch is controlled by a thread scheduler which takes into account whether a thread is waiting for I/O, synchronization, what its priority is, signal delivery, etc. Often there's a suspend count which is factored in.




• The debugger can increment the suspend count, which guarantees the thread isn't runnable. Then it can inspect (and change) the thread's saved copy of registers.

In addition to the great information by @BenVoigt, allow me to make some additions:

A breakpoint is set by the debugger by replacing a machine code value (an instruction or part of an instruction) in the process being debugged with a particular trap instruction at the location in code that corresponds to the desired (source) line to break at.  This particular trap instruction is meant for use as a breakpoint — the debugger knows this and so does the operating system.

When the process/thread being debugged hits the trap instruction, that triggers the process @Ben is describing, which includes the half of a context swap that suspends the currently running thread (which includes saving its CPU state to memory) for potential later resumption.  Since this trap is a breakpoint trap, the operating system keeps the process being debugged suspended using perhaps a mechanism @Ben describes, and notifies and eventually resumes the debugger.

The debugger uses system calls, then, to access the saved state of the suspended process/thread being debugged.

To execute (resume) the line of code that broke (which now has the particular trap instruction), the debugger will restore the original machine code value it overwrote with the breakpoint trap instruction, possibly set another trap somewhere else (e.g. if single stepping, or the user makes new breakpoints), and mark the process/thread as runnable, perhaps using a mechanism as @Ben describes.

Actual details can be more complicated, in that keeping a long running breakpoint that is hit means doing something like swapping out the breakpoint trap for real code so that line can run, and then swapping the breakpoint back in again...

Aren't those register being used by other OS processes constantly? how do they not get overwritten?

As @Ben describes, using the already existing thread suspend/resume feature (the context switching/swapping of multitasking) that allows processors to be shared by multiple processes/threads using time slicing.

Is it only a snapshot of the content and not live data?

It is both. Since the thread that hit the breakpoint is suspended, it a snapshot of the live data.  If you alter the CPU registers and resume the process, the debugger will alter the suspended register context using system calls — this suspended context lives in an operating system data structure for the thread — and when the process/thread being debugged resumes, it will restore the altered values.