Index: doc/theses/andrew_beach_MMath/unwinding.tex
===================================================================
--- doc/theses/andrew_beach_MMath/unwinding.tex	(revision c72ea7ada1279504439d99e4ecfee9a46c6da894)
+++ doc/theses/andrew_beach_MMath/unwinding.tex	(revision f28fdee903fa756068b5401d0fcf0c910d9ade16)
@@ -10,7 +10,7 @@
 Even this is fairly simple if nothing needs to happen when the stack unwinds.
 Traditional C can unwind the stack by saving and restoring state (with
-\codeC{setjmp} \& \codeC{longjmp}). However many languages define actions that
+@setjmp@ \& @longjmp@). However many languages define actions that
 have to be taken when something is removed from the stack, such as running
-a variable's destructor or a \codeCFA{try} statement's \codeCFA{finally}
+a variable's destructor or a @try@ statement's @finally@
 clause. Handling this requires walking the stack going through each stack
 frame.
@@ -29,6 +29,6 @@
 
 \CFA uses two primary functions in libunwind to create most of its
-exceptional control-flow: \codeC{_Unwind_RaiseException} and
-\codeC{_Unwind_ForcedUnwind}.
+exceptional control-flow: @_Unwind_RaiseException@ and
+@_Unwind_ForcedUnwind@.
 Their operation is divided into two phases: search and clean-up. The search
 phase -- phase 1 -- is used to scan the stack but not unwinding it. The
@@ -44,25 +44,25 @@
 A personality function performs three tasks, although not all have to be
 present. The tasks performed are decided by the actions provided.
-\codeC{_Unwind_Action} is a bitmask of possible actions and an argument of
+@_Unwind_Action@ is a bitmask of possible actions and an argument of
 this type is passed into the personality function.
 \begin{itemize}
-\item\codeC{_UA_SEARCH_PHASE} is passed in search phase and tells the
+\item@_UA_SEARCH_PHASE@ is passed in search phase and tells the
 personality function to check for handlers. If there is a handler in this
 stack frame, as defined by the language, the personality function should
-return \codeC{_URC_HANDLER_FOUND}. Otherwise it should return
-\codeC{_URC_CONTINUE_UNWIND}.
-\item\codeC{_UA_CLEANUP_PHASE} is passed in during the clean-up phase and
+return @_URC_HANDLER_FOUND@. Otherwise it should return
+@_URC_CONTINUE_UNWIND@.
+\item@_UA_CLEANUP_PHASE@ is passed in during the clean-up phase and
 means part or all of the stack frame is removed. The personality function
 should do whatever clean-up the language defines
 (such as running destructors/finalizers) and then generally returns
-\codeC{_URC_CONTINUE_UNWIND}.
-\item\codeC{_UA_HANDLER_FRAME} means the personality function must install
+@_URC_CONTINUE_UNWIND@.
+\item@_UA_HANDLER_FRAME@ means the personality function must install
 a handler. It is also passed in during the clean-up phase and is in addition
 to the clean-up action. libunwind provides several helpers for the personality
 function here. Once it is done, the personality function must return
-\codeC{_URC_INSTALL_CONTEXT}.
+@_URC_INSTALL_CONTEXT@.
 \end{itemize}
 The personality function is given a number of other arguments. Some are for
-compatability and there is the \codeC{struct _Unwind_Context} pointer which
+compatability and there is the @struct _Unwind_Context@ pointer which
 passed to many helpers to get information about the current stack frame.
 
@@ -72,5 +72,5 @@
 raise-exception but with some extras.
 The first it passes in an extra action to the personality function on each
-stack frame, \codeC{_UA_FORCE_UNWIND}, which means a handler cannot be
+stack frame, @_UA_FORCE_UNWIND@, which means a handler cannot be
 installed.
 
@@ -83,8 +83,8 @@
 stack frames have been removed. By the standard API this is marked by setting
 the stack pointer inside the context passed to the stop function. However both
-GCC and Clang add an extra action for this case \codeC{_UA_END_OF_STACK}.
+GCC and Clang add an extra action for this case @_UA_END_OF_STACK@.
 
 Each time function the stop function is called it can do one or two things.
-When it is not the end of the stack it can return \codeC{_URC_NO_REASON} to
+When it is not the end of the stack it can return @_URC_NO_REASON@ to
 continue unwinding.
 % Is there a reason that NO_REASON is used instead of CONTINUE_UNWIND?
@@ -113,5 +113,5 @@
 
 The stop function is very simple. It checks the end of stack flag to see if
-it is finished unwinding. If so, it calls \codeC{exit} to end the process,
+it is finished unwinding. If so, it calls @exit@ to end the process,
 otherwise it returns with no-reason to continue unwinding.
 % Yeah, this is going to have to change.
@@ -128,18 +128,18 @@
 location of the instruction pointer and stack layout, which varies with
 compiler and optimization levels. So for frames where there are only
-destructors, GCC's attribute cleanup with the \texttt{-fexception} flag is
+destructors, GCC's attribute cleanup with the @-fexception@ flag is
 sufficient to handle unwinding.
 
 The only functions that require more than that are those that contain
-\codeCFA{try} statements. A \codeCFA{try} statement has a \codeCFA{try}
-clause, some number of \codeCFA{catch} clauses and \codeCFA{catchResume}
-clauses and may have a \codeCFA{finally} clause. Of these only \codeCFA{try}
-statements with \codeCFA{catch} clauses need to be transformed and only they
-and the \codeCFA{try} clause are involved.
+@try@ statements. A @try@ statement has a @try@
+clause, some number of @catch@ clauses and @catchResume@
+clauses and may have a @finally@ clause. Of these only @try@
+statements with @catch@ clauses need to be transformed and only they
+and the @try@ clause are involved.
 
-The \codeCFA{try} statement is converted into a series of closures which can
+The @try@ statement is converted into a series of closures which can
 access other parts of the function according to scoping rules but can be
-passed around. The \codeCFA{try} clause is converted into the try functions,
-almost entirely unchanged. The \codeCFA{catch} clauses are converted into two
+passed around. The @try@ clause is converted into the try functions,
+almost entirely unchanged. The @catch@ clauses are converted into two
 functions; the match function and the catch function.
 
@@ -153,5 +153,5 @@
 runs the handler's body.
 
-These three functions are passed to \codeC{try_terminate}. This is an
+These three functions are passed to @try_terminate@. This is an
 % Maybe I shouldn't quote that, it isn't its actual name.
 internal hand-written function that has its own personality function and
@@ -167,7 +167,7 @@
 handler was found in this frame. If it was then the personality function
 installs the handler, which is setting the instruction pointer in
-\codeC{try_terminate} to an otherwise unused section that calls the catch
+@try_terminate@ to an otherwise unused section that calls the catch
 function, passing it the current exception and handler index.
-\codeC{try_terminate} returns as soon as the catch function returns.
+@try_terminate@ returns as soon as the catch function returns.
 
 At this point control has returned to normal control flow.
