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
projects / mono.git / blobdiff