Excellent! Keep up the good work! On Mon, Apr 14, 2008 at 2:06 AM, Adam Stevenson <[EMAIL PROTECTED]> wrote: > 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 >
-- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- 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
