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

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.