It is pretty much an AOT issue. I am still working on rewriting/simplifying the AOT and right now it works just fine with the test cases but not with the trunk kernel. :( We added more test cases but e still need more test cases. One way would be to take kernel methods and wrap them as test cases. Another way would be for example to re-implement the test cases of rotor (sscli20\tests\il_bvt\base)?
Bruce wrote: > Well, I've been doing quite a bit of follow-the-code, trying to figure > out why the trunk kernel, when compiled and then trunk-aoted, crashes. > (My biggest problem being, having not written the IDT code, and with > it not being fully documented ATM, I really didn't know what was going > on.) When an interrupt occurs the processor uses the idt field (IDT.cs:26) that is initialized in SetupISR and it jumps to ISR_XX (IDT.cs:435) where xx is the index of the interrupt that occurred. ISR_XX are defined as labels in ISRHandlers and they all jump to ISRDispatcher (IDT.cs:1711) and that does only read the address of the SharpOS c# handler (IDT.cs:1727-1731) that is setup in the ISRTable. ISRTable is the array that is containing the addresses of the Interrupt handlers and it is initialized with the address of ISR_DEFAULT_HANDLER (IDT.cs:144). That way SetupIRQ (IDT.cs:118) can be used to setup a new interrupt handler instead of updating the x86 idt table. Hopefully it was clear enough if not please let me know. Chriss. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
