Context Navigation

-                      r79e261b7
+                      rf28fdee
 All of this is accessed through a field inserted at the beginning of every
 virtual type. Currently it is called \codeC{virtual_table} but it is not
+virtual type. Currently it is called @virtual_table@ but it is not
 ment to be accessed by the user. This field is a pointer to the type's
 virtual table instance. It is assigned once during the object's construction
 …
 using that to calculate the mangled name of the parent's virtual table type.
 There are two special fields that are included like normal fields but have
 special initialization rules: the \codeC{size} field is the type's size and is
 initialized with a sizeof expression, the \codeC{align} field is the type's
+special initialization rules: the @size@ field is the type's size and is
+initialized with a sizeof expression, the @align@ field is the type's
 alignment and uses an alignof expression. The remaining fields are resolved
 to a name matching the field's name and type using the normal visibility
 …
 The declarations include the virtual type definition and forward declarations
 of the virtual table instance, constructor, message function and
 \codeCFA{get_exception_vtable}. The definition includes the storage and
+@get_exception_vtable@. The definition includes the storage and
 initialization of the virtual table instance and the bodies of the three
 functions.
 …
 from the per-instance information. The virtual table type and most of the
 functions are polymorphic so they are all part of the core. The virtual table
 instance and the \codeCFA{get_exception_vtable} function.
 Coroutines and threads need instances of \codeCFA{CoroutineCancelled} and
 \codeCFA{ThreadCancelled} respectively to use all of their functionality.
 When a new data type is declared with \codeCFA{coroutine} or \codeCFA{thread}
+instance and the @get_exception_vtable@ function.
+Coroutines and threads need instances of @CoroutineCancelled@ and
+@ThreadCancelled@ respectively to use all of their functionality.
+When a new data type is declared with @coroutine@ or @thread@
 the forward declaration for the instance is created as well. The definition
 of the virtual table is created at the definition of the main function.
 …
 function.
 The function is \codeC{__cfa__virtual_cast} and it is implemented in the
+The function is @__cfa__virtual_cast@ and it is implemented in the
 standard library. It takes a pointer to the target type's virtual table and
 the object pointer being cast. The function is very simple, getting the
 …
 For the generated code a forward decaration of the virtual works as follows.
 There is a forward declaration of \codeC{__cfa__virtual_cast} in every cfa
+There is a forward declaration of @__cfa__virtual_cast@ in every cfa
 file so it can just be used. The object argument is the expression being cast
 so that is just placed in the argument list.
 …
 often across functions.
 At a very basic level this can be done with \codeC{setjmp} \& \codeC{longjmp}
+At a very basic level this can be done with @setjmp@ \& @longjmp@
 which simply move the top of the stack, discarding everything on the stack
 above a certain point. However this ignores all the clean-up code that should
 …
 both of these problems.
 Libunwind, provided in \texttt{unwind.h} on most platorms, is a C library
+Libunwind, provided in @unwind.h@ on most platorms, is a C library
 that provides \CPP style stack unwinding. Its operation is divided into two
 phases. The search phase -- phase 1 -- is used to scan the stack and decide
 …
 GCC will generate an LSDA and attach its personality function with the
 \texttt{-fexceptions} flag. However this only handles the cleanup attribute.
+@-fexceptions@ flag. However this only handles the cleanup attribute.
 This attribute is used on a variable and specifies a function that should be
 run when the variable goes out of scope. The function is passed a pointer to
 …
 messages for special cases (some of which should never be used by the
 personality function) and error codes but unless otherwise noted the
 personality function should always return \codeC{_URC_CONTINUE_UNWIND}.
 The \codeC{version} argument is the verson of the implementation that is
+personality function should always return @_URC_CONTINUE_UNWIND@.
+The @version@ argument is the verson of the implementation that is
 calling the personality function. At this point it appears to always be 1 and
 it will likely stay that way until a new version of the API is updated.
 The \codeC{action} argument is set of flags that tell the personality
+The @action@ argument is set of flags that tell the personality
 function when it is being called and what it must do on this invocation.
 The flags are as follows:
 \begin{itemize}
 \item\codeC{_UA_SEARCH_PHASE}: This flag is set whenever the personality
+\item@_UA_SEARCH_PHASE@: This flag is set whenever the personality
 function is called during the search phase. The personality function should
 decide if unwinding will stop in this function or not. If it does then the
 personality function should return \codeC{_URC_HANDLER_FOUND}.
 \item\codeC{_UA_CLEANUP_PHASE}: This flag is set whenever the personality
+personality function should return @_URC_HANDLER_FOUND@.
+\item@_UA_CLEANUP_PHASE@: This flag is set whenever the personality
 function is called during the cleanup phase. If no other flags are set this
 means the entire frame will be unwound and all cleanup code should be run.
 \item\codeC{_UA_HANDLER_FRAME}: This flag is set during the cleanup phase
+\item@_UA_HANDLER_FRAME@: This flag is set during the cleanup phase
 on the function frame that found the handler. The personality function must
 prepare to return to normal code execution and return
 \codeC{_URC_INSTALL_CONTEXT}.
 \item\codeC{_UA_FORCE_UNWIND}: This flag is set if the personality function
+@_URC_INSTALL_CONTEXT@.
+\item@_UA_FORCE_UNWIND@: This flag is set if the personality function
 is called through a forced unwind call. Forced unwind only performs the
 cleanup phase and uses a different means to decide when to stop. See its
 …
 \end{itemize}
 The \codeC{exception_class} argument is a copy of the \codeC{exception}'s
 \codeC{exception_class} field.
 The \codeC{exception} argument is a pointer to the user provided storage
+The @exception_class@ argument is a copy of the @exception@'s
+@exception_class@ field.
+The @exception@ argument is a pointer to the user provided storage
 object. It has two public fields, the exception class which is actually just
 a number that identifies the exception handling mechanism that created it and
 …
 exception needs to
 The \codeC{context} argument is a pointer to an opaque type. This is passed
+The @context@ argument is a pointer to an opaque type. This is passed
 to the many helper functions that can be called inside the personality
 function.
 …
 functions traversing the stack new-to-old until a function finds a handler or
 the end of the stack is reached. In the latter case raise exception will
 return with \codeC{_URC_END_OF_STACK}.
+return with @_URC_END_OF_STACK@.
 Once a handler has been found raise exception continues onto the the cleanup
 …
 If an error is encountered raise exception will return either
 \codeC{_URC_FATAL_PHASE1_ERROR} or \codeC{_URC_FATAL_PHASE2_ERROR} depending
+@_URC_FATAL_PHASE1_ERROR@ or @_URC_FATAL_PHASE2_ERROR@ depending
 on when the error occured.
 …
 been unwound.
 Each time it is called the stop function should return \codeC{_URC_NO_REASON}
+Each time it is called the stop function should return @_URC_NO_REASON@
 or transfer control directly to other code outside of libunwind. The
 framework does not provide any assistance here.
 Its arguments are the same as the paired personality function.
 The actions \codeC{_UA_CLEANUP_PHASE} and \codeC{_UA_FORCE_UNWIND} are always
+The actions @_UA_CLEANUP_PHASE@ and @_UA_FORCE_UNWIND@ are always
 set when it is called. By the official standard that is all but both GCC and
 Clang add an extra action on the last call at the end of the stack:
 \codeC{_UA_END_OF_STACK}.
+@_UA_END_OF_STACK@.
 \section{Exception Context}
 …
 Each stack has its own exception context. In a purely sequental program, using
 only core Cforall, there is only one stack and the context is global. However
 if the library \texttt{libcfathread} is linked then there can be multiple
+if the library @libcfathread@ is linked then there can be multiple
 stacks so they will each need their own.
 To handle this code always gets the exception context from the function
 \codeC{this_exception_context}. The main exception handling code is in
 \texttt{libcfa} and that library also defines the function as a weak symbol
 so it acts as a default. Meanwhile in \texttt{libcfathread} the function is
+@this_exception_context@. The main exception handling code is in
+@libcfa@ and that library also defines the function as a weak symbol
+so it acts as a default. Meanwhile in @libcfathread@ the function is
 defined as a strong symbol that replaces it when the libraries are linked
 together.
 The version of the function defined in \texttt{libcfa} is very simple. It
+The version of the function defined in @libcfa@ is very simple. It
 returns a pointer to a global static variable. With only one stack this
 global instance is associated with the only stack.
 The version of the function defined in \texttt{libcfathread} has to handle
+The version of the function defined in @libcfathread@ has to handle
 more as there are multiple stacks. The exception context is included as
 part of the per-stack data stored as part of coroutines. In the cold data
 section, stored at the base of each stack, is the exception context for that
 stack. The \codeC{this_exception_context} uses the concurrency library to get
+stack. The @this_exception_context@ uses the concurrency library to get
 the current coroutine and through it the cold data section and the exception
 context.
 …
 to store the exception. Macros with pointer arthritic and type cast are
 used to move between the components or go from the embedded
 \codeC{_Unwind_Exception} to the entire node.
+@_Unwind_Exception@ to the entire node.
 All of these nodes are strung together in a linked list. One linked list per
 …
 C which is what the \CFA compiler outputs so a work-around is used.
 This work around is a function called \codeC{__cfaehm_try_terminate} in the
+This work around is a function called @__cfaehm_try_terminate@ in the
 standard library. The contents of a try block and the termination handlers
 are converted into functions. These are then passed to the try terminate
 …
 These nested functions and all other functions besides
 \codeC{__cfaehm_try_terminate} in \CFA use the GCC personality function and
 the \texttt{-fexceptions} flag to generate the LSDA. This allows destructors
+@__cfaehm_try_terminate@ in \CFA use the GCC personality function and
+the @-fexceptions@ flag to generate the LSDA. This allows destructors
 to be implemented with the cleanup attribute.
 …
 The handler function does both the matching and catching. It tries each
 the condition of \codeCFA{catchResume} in order, top-to-bottom and until it
+the condition of @catchResume@ in order, top-to-bottom and until it
 finds a handler that matches. If no handler matches then the function returns
 false. Otherwise the matching handler is run, if it completes successfully
 the function returns true. Rethrows, through the \codeCFA{throwResume;}
+the function returns true. Rethrows, through the @throwResume;@
 statement, cause the function to return true.
 …
 Cancellation also uses libunwind to do its stack traversal and unwinding,
 however it uses a different primary function \codeC{_Unwind_ForcedUnwind}.
+however it uses a different primary function @_Unwind_ForcedUnwind@.
 Details of its interface can be found in the unwind section.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset f28fdee for doc/theses/andrew_beach_MMath/implement.tex

Legend:

doc/theses/andrew_beach_MMath/implement.tex

Download in other formats: