Cfrgtkky

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 (CPU registers, etc..) at the time of suspension, and the authoritative master of the CPU register values to restore into the processor should the thread be resumed.  If you use the debugger's user interface to read and/or change the CPU registers (of the process being debugged) it will read and/or change this snapshot/master using system calls.

Strictly speaking, at least in most typical cases, gdb itself doesn't pause execution. Rather, gdb asks the OS, and the OS pauses execution.

That might initially seem like a distinction without a difference--but honest, there really is a difference. The difference is this: that ability is already built into the typical OS, because it has to be able to pause and re-start execution of thread anyway--when a thread isn't scheduled to run (e.g., it needs some resource that isn't currently available) the OS needs to pause it until it can be scheduled to run.

To do that, the OS typically has a block of memory set aside for each thread to save the current state of the machine. When it needs to pause a thread, the machine's current state is saved in that area. When it needs to resume a thread, the machine's state is restored from that area.

When the debugger needs to pause a thread, it has the OS pause that thread exactly the same way it would for other reasons. Then, to read the state of the paused thread, the debugger looks at the thread's saved state. If you modify the state, the debugger writes to the saved state, when then takes effect when the thread is resume.