source: doc/theses/lynn_tran_SE499/Chapters/GDB.tex @ a5a08a05

\chapter{GNU Debugger} \label{GDB}

\section{Introduction}
The GNU Project Debugger is a program that allows examination of what is going on
inside another program while it executes, or examines the state of a program
after it crashed \cite{Reference3}.

\section{Debug Information}
In order to allow effective inspection of program state, the
debugger requires debugging information for a program. Debugging
information is a collection of data generated by a compiler and/or an assembler
program. This information is optional as it is only required for compilation,
and hence, it is normally not present during program execution when debugging
occurs. When requested, debugging information is stored in an object file, and it describes
information such as the type of each variable or function and
the correspondence between source line numbers and addresses in the executable
code \cite{Reference6}. Debugging information is requested via the \verb|-g|
flag during the compilation stage of the
program.

The debugging information must be written out in a canonical format for
debuggers to read. DWARF is one of the supported debugging data formats, and its architecture is
independent and applicable to any language, operating system, or processor \cite{Reference7}. This format uses a data structure called DIE to represent
each variable, type, function, etc. A DIE is a pair: tag
and its attribute \cite{Reference8}.

\section{Stack-Frame Information}
A stack frame, or frame for short, is a collection of all data associated with
one function call. A frame consists of parameters received from the function call, local variables declared in that
function, and the address where the
function returns. The frame-pointer register stores the address of a frame,
during execution of a call. A call stack can have many frames \cite{Reference12}.

\section{Extending GDB}
GDB provides three mechanisms for extending itself. The first is
composition of GDB commands, the second is using the Python GDB API, and the third is defining new aliases for existing commands.

\section{Symbol Handling}
Symbols are a key part of GDB's operation. Symbols can be variables, functions and
types. GDB has three kinds of symbol tables:
\begin{itemize}
    \item \textcolor{ForestGreen}{Full symbol-tables (symtabs)}: These contain the main information
        about symbols and addresses
    \item \textcolor{ForestGreen} {Partial symbol-tables (psymtabs)}: These contain enough information to
        know when to read the corresponding part of the full symbol-table.
    \item \textcolor{ForestGreen}{Minimal symbol-tables (msymtabs)}: These
        contain information extracted from non-debugging symbols.
\end{itemize}

Debugging information for a large program can be very large, and reading all of
these symbols can be a performance bottleneck in GDB, affecting the user
experience. The solution is to lazily construct partial symbol-tables consisting of
only selected symbols, and then eagerly expand them to full symbol-tables when
necessary.
The psymtabs is constructed by doing a quick pass over the executable file's
debugging information.

\section{Name Demangling in GDB}
The library \verb|libiberty| provides many functions and features that can be
divided into three groups:
\begin{itemize}
    \item \textcolor{ForestGreen}{Supplemental functions}: additional functions
        that may be missing in
        the underlying operating system.
    \item \textcolor{ForestGreen}{Replacement functions}: simple and unified equivalent functions for
        commonly used standard functions.
    \item \textcolor{ForestGreen}{Extensions}: additional functions beyond the standard.
\end{itemize}

In particular, this library provides the \CC demangler that is used in GDB and
by \uC. A new
demangler can also be added in this library, which is what Rust did, and what
is necessary for \CFA.