source: doc/theses/lynn_tran_SE499/Chapters/Introduction.tex @ b965774

Last change on this file since b965774 was 1b34b87, checked in by Peter A. Buhr <pabuhr@…>, 6 years ago

Lynn's GDB essay

  • Property mode set to 100644
File size: 4.1 KB
Line 
1\chapter{Introduction} \label{introduction}
2Computer programming languages provide humans a means to instruct computers to
3perform a particular task. New programming languages are
4invented to simplify the task, or provide additional features, enhance
5performance, and improve developer productivity.
6
7A crucial companion tool to a programming language is a debugger. A debugger is a productivity tool to aid developers in testing
8and finding bugs in a program. By definition, a debugger executes
9any program written in one of a supported set of languages and allows developers
10to stop, monitor and examine state in the program for further investigation.
11
12Specifically, this report talks about how to add GNU Debugger (GDB) support for the
13concurrent programming-languages \uC and \CFA.
14Both languages provide an $M$:$N$ concurrency model, where $M$ user-level threads
15execute on $N$ kernel-level threads.
16Often debuggers either do not know about concurrency or only provide a simple
17understanding of concurrency provided by the operating system (kernel threads).
18For \CFA, new hooks are also added to allow GDB to understand that
19\CFA is a new source language that requires invocation of a demangler for
20variable and function names.
21
22Because \uC is a translator, all the code written in \uC is eventually
23compiled down to \CC code. This transformation gives \uC an advantage with
24GDB because GDB already understands \CC. However, since \uC introduced new objects
25and high-level execution constructs into the language, GDB does not understand
26these objects or the runtime environment. One objective of this
27project is to write new GDB extensions to understand concurrency among tasks, a new high-level execution construct that is discussed more in Chapter \ref{uC}.
28
29Additionally, if a programming language provides overloading functionality,
30which allows functions or variables in the same scope with the
31same identifier, then each of these entities must be assigned a unique name, otherwise,
32there are name collisions.
33
34However, uniquely numbering (naming) overloads is impossible with separate
35compilation, because the compiler does not have access to all translation
36units. Therefore, it is necessary to adopt a scheme related to the overloading
37mechanism for unique naming. For example, if a language uses the number and
38types of function parameters to disambiguate function names, than the number
39and parameter types are encoded into the name:
40\begin{lstlisting}[basicstyle=\normalfont\tt]
41void f( int i, double d, char c );  // f_3_i_d_c
42void f( int i, char c );            // f_2_i_c
43\end{lstlisting}
44Here, the mangled names for \lstinline@f@ contain the number of parameters and a code for
45each parameter type. For a complex type-system, the type codes become
46correspondingly complex, e.g., a generic structure. These names are now unique
47across all translation units.
48
49Unfortunately, a debugger only has access to the mangled names in a compiled
50translation units, versus the unmangled names in the program.  Therefore, the
51debugger can only look up mangled names versus original program names, which
52makes debugging extremely difficult for programmers. To solve this program, the
53language must provide the debugger with a "demangled" so it can convert
54mangled names back to program names, and correspondingly retrieve the type of
55the name~\cite{Reference9}.
56
57\CFA, a new language being developed at the University of Waterloo, has
58overloading, so names resolved by the debugger are mangled names. Therefore,
59another objective of this project is to add a \CFA demangler to GDB.
60
61% Name mangling is a technique used in compilers to resolve this
62% problem. This technique provides a mechanism to encode additional information in the
63% name of a function, or a variable to supply more semantic information from
64% compiler to debugger \cite{Reference9}. \CFA, a new language being developed at the University of
65% Waterloo, has overloading, so names resolved from
66% the debugger are mangled names. As with early versions of \CC, it is not user-friendly to debug a program using
67% mangled names. Therefore, another objective of this project is to add a \CFA demangler in GDB.
Note: See TracBrowser for help on using the repository browser.