An unedited draft is now loaded on the wiki at:
http://www.sharpos.org/redmine/wiki/7/Exception_Handling

On Sun, Apr 13, 2008 at 6:21 PM, grover <[EMAIL PROTECTED]> wrote:
>
>
> 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
>
>

-------------------------------------------------------------------------
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

Reply via email to