how does gdb work?

I want to know how does gdb work internally. e.g. I know a brief idea that it makes use of ptrace() system call to monitor traced program. But I want to know how it handles 开发者_C百科signals, how it inserts new code, and other such fabulous things it does.

---

Check out the GDB Internals Manual, which covers some of the important aspects. There's also an older PDF version of this document.

From the manual:

This document documents the internals of the GNU debugger, gdb. It includes description of gdb's key algorithms and operations, as well as the mechanisms that adapt gdb to specific hosts and targets.

---

Taken from gdbint.pdf:

It can be done either as hardware breakpoints or as software breakpoints:

• Hardware breakpoints are sometimes available as a builtin debugging features with some chips. Typically these work by having dedicated register into which the breakpoint address may be stored. If the PC (shorthand for program counter) ever matches a value in a breakpoint registers, the CPU raises an exception and reports it to GDB.
• Another possibility is when an emulator is in use; many emulators include circuitry that watches the address lines coming out from the processor, and force it to stop if the address matches a breakpoint's address.
• A third possibility is that the target already has the ability to do breakpoints somehow; for instance, a ROM monitor may do its own software breakpoints. So although these are not literally hardware breakpoints, from GDB's point of view they work the same;
• Software breakpoints require GDB to do somewhat more work. The basic theory is that GDB will replace a program instruction with a trap, illegal divide, or some other instruction that will cause an exception, and then when it's encountered, GDB will take the exception and stop the program. When the user says to continue, GDB will restore the original instruction, single-step, re-insert the trap, and continue on.

---

The only way you'll find out is by studying the source.

You can also build it and debug it with itself. Step through the code, and you'll know exactly how it does what it does.

Reading GDB source is not for the faint of heart though -- it is chock-full of macros, and heavily uses libbfd, which itself is hard to understand.

It has to, because it is portable (and in particular, builds and works on platforms which do not have ptrace() at all).