This blog is intended to give a brief overview of GDB and some internal features. GDB is an interactive tool. GDB should be responsive to the user.
GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:
* Start your program, specifying anything that might affect its behavior.
* Make your program stop on specified conditions.
* Examine what has happened, when your program has stopped.
* Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.
GDB consists of three major subsystems:
1. User interface: The user interface consists of several actual interfaces, plus supporting code.
2. Symbol handling (the symbol side): The symbol side consists of object file readers, debugging info interpreters, symbol table management, source language expression parsing, type and value printing.
3.Target system handling (the target side): The target side consists of execution control, stack frame analysis, and physical target manipulation.
GDB uses a technique called prologue analysis to find frame sizes and saved registers. A prologue analyzer disassembles the function's machine code starting from its entry point, and looks for instructions that allocate frame space, save the stack pointer in a frame pointer register, save registers, and so on.
Breakpoint Handling:
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 program counter ever matches a value in a breakpoint registers, the CPU raises an exception and reports it to gdb.
No comments:
Post a Comment