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 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:



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).


Taken from gdbint.pdf:

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

  • 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.

Your Answer

