16

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?

  • 2
    How come all the registers don't get overwritten when the OS decides to pause your program for a moment and run a different one? – immibis Jan 27 at 7:04
  • CppCon 2018: Simon Brand “How C++ Debuggers Work” youtube.com/watch?v=0DDrseUomfU – Robert Andrzejuk Jan 27 at 9:31
24

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.

14

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.

  • 1
    Well, most processor architectures support debug traps that for example trigger when the IP (instruction pointer) is equal to the address stored in a breakpoint register, saving the need to rewrite code. (By matching registers other than IP, you can get data breakpoints, and by trapping after every instruction, you can get single stepping) What you described is also possible of course, as long as the code isn't in a readonly memory. – Ben Voigt Jan 27 at 1:49
  • Re "If you alter the CPU registers..." in the last paragraph, I think you mean "If you alter the saved copy of the CUP registers..." Then when the OS resumes the process, that altered data is written back to the actual registers. – jamesqf Jan 27 at 5:14
  • @jamesqf, yes, thx! – Erik Eidt Jan 27 at 5:39
  • @BenVoigt, agreed. though while debuggers can handle unlimited numbers of breakpoints, hardware can handle zero or a few, so the debugger has to do some juggling. – Erik Eidt Jan 27 at 6:10
  • @jamesqf: Describing that as a copy is a bit misleading. It's the official storage for the thread state while the thread isn't running. – Ben Voigt Jan 27 at 17:10
5

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.