diff options
Diffstat (limited to 'docs/exceptions')
-rw-r--r-- | docs/exceptions | 64 |
1 files changed, 52 insertions, 12 deletions
diff --git a/docs/exceptions b/docs/exceptions index 05f1be03bba..d5ecaeead43 100644 --- a/docs/exceptions +++ b/docs/exceptions @@ -1,5 +1,6 @@ -Author: Dietmar Maurer (dietmar@ximian.com) -(C) 2001 Ximian, Inc. + Exception Implementation in the Mono Runtime + Dietmar Maurer (dietmar@ximian.com) + (C) 2001 Ximian, Inc. Exception implementation (jit): =============================== @@ -56,15 +57,54 @@ leave: is simply translated into a branch to the target. If the leave instruction is inside a finally block (but not inside another handler) we call the finally handler before we branch to the target. -finally/endfinally: is translated into subroutine ending with a "return" -statement. The subroutine does not save EBP/ESP, because we need access to the -local variables of the enclosing method. We have to use a "call" -instruction to execute such finally handlers. This makes it possible to -execute them inside the stack unwinding code. +finally/endfinally, filter/endfilter: is translated into subroutine ending with +a "return" statement. The subroutine does not save EBP, because we need access +to the local variables of the enclosing method. Its is possible that +instructions inside those handlers modify the stack pointer, thus we save the +stack pointer at the start of the handler, and restore it at the end. We have +to use a "call" instruction to execute such finally handlers. This makes it +also possible to execute them inside the stack unwinding code. The exception +object for filters is passed in a local variable (cfg->exvar). -throw: we first save all regs into a sigcontext struct (we pass the -exception object in register ECX), and then call the stack unwinding -code. +throw: we first save all regs into a sigcontext struct and then call the stack +unwinding code. -catch handler: receives the exception object in ECX. They store that -object into a local variable, so that rethrow can access the object. +catch handler: catch hanlders are always called from the stack unwinding +code. The exception object is passed in a local variable (cfg->exvar). + +gcc support for Exceptions +========================== + +gcc supports exceptions in files compiled with the -fexception option. gcc +generates DWARF exceptions tables in that case, so it is possible to unwind the +stack. The method to read those exception tables is contained in libgcc.a, and +in newer versions of glibc (glibc 2.2.5 for example), and it is called +__frame_state_for(). Another usable glibc function is backtrace_symbols() which +returns the function name corresponding to a code address. + +We dynamically check if those features are available using g_module_symbol(), +and we use them only when available. If not available we use the LMF as +fallback. + +Using gcc exception information prevents us from saving the LMF at each native +call, so this is a way to speed up native calls. This is especially valuable +for internal calls, because we can make sure that all internal calls are +compiled with -fexceptions (we compile the whole mono runtime with that +option). + +All native function are able to call function without exception tables, and so +we are unable to restore all caller saved registers if an exception is raised +in such function. Well, its possible if the previous function already saves all +registers. So we only omit the the LMF if a function has an exception table +able to restore all caller saved registers. + +One problem is that gcc almost never saves all caller saved registers, because +it is just unnecessary in normal situations. But there is a trick forcing gcc +to save all register, we just need to call __builtin_unwind_init() at the +beginning of a function. That way gcc generates code to save all caller saved +register on the stack. + + + + +
\ No newline at end of file |