Jump to content

- - - - -

How does a debugger like GDB work

  • Please log in to reply
3 replies to this topic

#1 Spyril


    Hakker addict

  • Members
  • 588 posts
  • Location:North Dakota

Posted 31 July 2008 - 08:05 PM

I've been wondering how the internals of gdb, and similar debuggers, work. How do they "attach" themselves to programs? (I know they read a certain sector of memory that the program is occupying, but how do they find this certain sector of memory? Are there some OS-specific system calls?) Also, I know downloading the "debug info" for a program allows you to debug it, but what information does the debug info contain?

I don't know much about assembly (and I don't know if that makes a difference) but I'm starting to learn; in the meantime I'm just curious as to how these debugging programs work.

Some links to information about this would be helpful; I'm not finding much on Google. Thanks in advance.

#2 Zeph


    OMG, so close to "1337"!

  • Agents of the Revolution
  • 1,319 posts

Posted 31 July 2008 - 08:12 PM

Using the ptrace() system call I believe.

#3 livinded


    Dangerous free thinker

  • Agents of the Revolution
  • 1,942 posts
  • Location:~/

Posted 31 July 2008 - 08:19 PM

what functionality of the debugger are you talking about. Yes ptrace (on linux) is used in debugging allowing the debugger to attach to the process and read it's memory, interact, set breakpoints etc. in many cases. However working with interpreted languages you can embed the interpreter into a debugger and not have to attach to the process but interact directly with the interpreter.

#4 duper


    Dangerous free thinker

  • Members
  • 816 posts
  • Location:NYC

Posted 31 July 2008 - 09:47 PM

For Intel, the INT 3h instruction is used to set breakpoints. The debugger overwrites the instruction at the location where the breakpoint is to be set with INT 3h, and saves the original instruction. Then, when the program counter reaches that location, the debugger stops execution of the debugee, rewrites the original instruction back to that location where the breakpoint was and prompts the user for further action.

Debugging symbols contain and name, location, and type information for variables and functions throughout the binary. The debugger unravels the call stack frame by frame by looking at the stack pointer (stored in a special register which varies from platform to platform) and performs some pointer arithmetic to determine the parent of the current function. Without debug information, it will only be able to display hexadecimal addresses and such, with debugging symbols it will be able to display detailed information about the functions that have been called and the variables that have been passed into them. The debug info also allows the program to associate the current instruction with a particular line of code (if the source code is available to the debugger.)

BinRev is hosted by the great people at Lunarpages!