Hello,
I have the following general remarks:
- First of all good work. A comparison to common implementations on other
platforms (languages) would be nice. I'd like to see a comparison to SEH
used by Windows/ReactOS and standard C++ exception handling as done by GCC
(if time allows this.)
- The third function called in the process of resolving stack frames is
probably the architecture specific stack walking function. This should
probably made explicit, that the target architecture is involved in this for
the stack walk.
- Third: Can we move this stuff to the wiki to enable everyone to contribute
instead of circulating this stuff in mails? A link to the wiki page would
suffice.
grover
_____
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von
Zachary Gorden
Gesendet: Sonntag, 13. April 2008 22:40
An: sharpos-developers@lists.sourceforge.net
Betreff: [SharpOS Developers] Documentation on exception handling
This is a draft of what I have so far. The part talking about the encoding
done by AOT still feels a bit weak, but that might just be because I don't
know much about compiler design and implementation. The last part about
what the runtime does will need a few more references, which I'll add later.
This is just to let you guys see what's been done so far and I know some of
you wanted this information quickly. Comments are welcome.
Exception Handling Setup in AOT and Runtime
Exception handling is often the first line of defense for an application
that encounters an error. Even when it fails to keep the program from
crashing, it can provide information that helps with finding the cause of
the error.
When a method is processed by the AOT, it is split into blocks as a step in
optimization. If these blocks possess exception handling code, they are
further divided. These blocks can have a series of flags that describe its
contents, which are marked by the MarkBlocks method in Method.cs. Also in
MarkBlocks, the CIL exception handling structures are converted to the
internal exception handling structures, the ExceptionHandlingClause class.
This class stores the beginning and end of each component of exception
handling, a reference to the exception class if one exists, and the type of
the exception handler. The types are organized as an enumeration and can be
Catch, Filter, Finally, or Fault.
The next step is to encode the exception clauses. This basically requires a
1:1 match between the ExceptionHandlingClause in the AOT and the one in the
runtime. Not only that, but the machine addresses of the exception handling
blocks must be included. At this time, we don't know the addresses that will
ultimately be used, so a series of labels are applied. These labels get
replaced when the actual conversion to x86, or whatever platform specific
machine code you're on, occurs.
We're now out of the setup the AOT needs to do and onto what happens when an
exception actually occurs. First we'll introduce the data structure that
facilitates printing out the trace of method calls that lead up to the
exception, then go over what actually happens when an exception is thrown.
The StackFrame data structure compose a list that tell you the exact chain
of calls up to where the exception occurred. The IP pointer points to where
in the method it passed control over to the next method in the chain. BP
points to the stack that holds the information a method would need to resume
execution. MethodBoundary obviously tells you where the method starts and
stops. In situations where there are multiple exception handling clauses, an
array of booleans with enough elements to represent each clause is created.
When an element is marked as false, that means that clause has not yet been
processed. Once it is processed, it is set to true so it will be ignored in
the current iteration. This both prevents infinite looping through the
exception handling and unpredictable results that might occur in repeatedly
going into old clauses.
When an exception is thrown, the code in
kernel/core/korlib/runtime/runtime.cs gets tripped. The principle function
is Throw(InternalSystem.Exception exception, int skipFrames). The first
parameter is the exception being thrown and the second is the number of
frames to ignore before we get to the method where the exception actually
occurred. This second parameter is needed because in the process of handling
the exceptions, various functions are called in the runtime. By the time we
get to properly handling the exception, we need to know how many methods
have been called in the interval so we can get down to the stack we really
want.
This number is usually three, for the following reason. When an exception is
thrown, the Throw(exception) method is called. This method then calls on
Throw(exception, skipFrames). This second Throw method calls one final
method in order to get a list of the stacks. However, because the method
will return the stacks from its current position, we will also get the stack
it used. As such, the list has three extra stacks on top of the one we're
interested in. Of course, this is only the case if this execution path was
followed. Other situations are possible where a different number of
skipFrames are passed in by certain methods.
Once this is handled, we need to check whether this is a throw or a rethrow.
A rethrow occurs when an exception is explicitly thrown using the "throw"
method. In such a situation, the VES will rethrow the exception. If the
method has code to handle the exception, its stack will be increased to hold
the exception. It is increased again to store the ESP, used for finally,
fault, or filter so that it can return to the runtime throw method to look
for other handlers. Conversely, an exception that is tripped but not
explicitly thrown will need to have the method's stack initialized. In this
case, the runtime's Throw(exception, skipFrames) method will do it.
Ultimately, it is the runtime that looks through the exception handling
blocks the AOT encoded and choose which, if any, are appropriate for the
exception that got thrown. The code in question is in runtime.cs at line
1027.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
