How does a breakpoint in debugger work?

debugging compiler-construction gdb breakpoints
Shan picture Shan · Jan 30, 2013 · Viewed 17.9k times · Source

Breakpoints are one of the coolest feature supported by most popular Debuggers like GDB. But how a breakpoint works ? What code modifications does the compiler do to achieve the breakpoint? Are there any special hardware features used to support breakpoints?

Answer

dbrank0 picture dbrank0 · Jan 30, 2013

Compiler does not need to "modify" the binary in any way to support the breakpoints. However it is important, that:

  • Compiler includes enough information in the executable (that is not in the code itself but in special sections in same file), so that debugger can relate source that user wants to debug with machine code. One typical thing debugger needs to know to be able to set breakpoints (unless you specify addresses directly), is where (at which address) program functions and lines of source code start (within machine code).
  • Code is not optimized by compiler in any way, that makes it impossible to relate source and machine code. Typically you will want debug code that was not optimized or code where only carefully selected optimizations were performed.

The rest of work is then performed by debugger itself.

  1. Software breakpoints don't necessarily need special hardware features. Debugger here relies on modifying original binary (it's copy that is loaded to memory). When you set a breakpoint, debugger will place special instruction at the location of breakpoint. This special instruction needs to somehow let debugger detect when it (this special instruction) is executing. This can be some instruction that causes some kind of interrupt/exception, that debugger can hook onto, or some instruction that handles the control to debug unit. If this runs under some OS, that OS needs to support modifying running program (with something like ptrace poke/peek). Downside of SW breakpoints is that debugger needs to be able to modify running program, which is not possible if program is running from some kind of read-only memory (quite common in embedded world).
  2. Hardware breakpoints (which need to be supported by CPU) implement similar behavior without modifying program binary. This is CPU specific, but usually it lets you to at least define a program address at which execution should hit a breakpoint. CPU continuously compares current PC with these breakpoint addresses and once the condition is matched, it breaks the execution. Number of these breakpoints is always limited.

Related questions

Codelite debugger error: Failed to locate gdb! at 'gdb'?

I'm trying using Codelite to try and compile some c++ projects that I wrote using DevCpp. I don't have a lot of knowledge about compilers and debuggers.. and every time I try to compile and debug any code in Codelite, …

Read More
How to tell if a binary is release or debug in both win and *nix

Is there a simple command line utility to inspect binaries like executable and dynamic libraries to tell if they are release or debug versions? Is there anything like that on *nix or windows?

Read More
Where to learn about VS debugger 'magic names'

If you've ever used Reflector, you probably noticed that the C# compiler generates types, methods, fields, and local variables, that deserve 'special' display by the debugger. For instance, local variables beginning with 'CS$' are not displayed to the user. …

Read More