diff options
author | Dietmar Maurer <dietmar@mono-cvs.ximian.com> | 2003-05-22 20:04:53 +0400 |
---|---|---|
committer | Dietmar Maurer <dietmar@mono-cvs.ximian.com> | 2003-05-22 20:04:53 +0400 |
commit | 9bc145b02b326b5aae985d4480966b5ee392f69c (patch) | |
tree | 766a762cac4f5790858ee3e99c88ff288cea4ce9 /docs | |
parent | f4656c2d26bca23f3e3789d59c0a8374146dd68c (diff) |
2003-05-22 Dietmar Maurer <dietmar@ximian.com>
* exceptions-x86.c (mono_arch_handle_exception): bug fix.
* more docu
svn path=/trunk/mono/; revision=14803
Diffstat (limited to 'docs')
-rw-r--r-- | docs/exceptions | 9 | ||||
-rw-r--r-- | docs/mini-porting.txt | 15 |
2 files changed, 17 insertions, 7 deletions
diff --git a/docs/exceptions b/docs/exceptions index d2d810ba7d0..ab76c0f97af 100644 --- a/docs/exceptions +++ b/docs/exceptions @@ -62,16 +62,15 @@ 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. Filters receives -the exception object in ECX. +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. -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 ========================== diff --git a/docs/mini-porting.txt b/docs/mini-porting.txt index 75af68c1f83..918ac8d1c68 100644 --- a/docs/mini-porting.txt +++ b/docs/mini-porting.txt @@ -272,8 +272,7 @@ To make this possible we implement them like subroutines, ending with a 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. Filters -receives the exception object inside a register (ECX on x86). +have to use a "call" instruction to execute such finally handlers. The MIR code for filter and finally handlers looks like: @@ -296,6 +295,18 @@ we simply emit a call instruction to invoke the handler. Its usually possible to use the same code to call filter and finally handlers (see arch_get_call_filter). +** Calling catch handlers + +Catch handlers are always called from the stack unwinding code. Unlike finally clauses +or filters, catch handler never return. Instead we simply restore the whole +context, and restart execution at the catch handler. + +** Passing Exception objects to catch handlers and filters. + +We use a local variable to store exception objects. The stack unwinding code +must store the exception object into this variable before calling catch handler +or filter. + * Minor helper methods A few minor helper methods are referenced from the arch-independent code. |