Tutorial 15: Errors, Exceptions, Interruptions

[Mike]

Hey everyone,

Tutorial 15 is planned for release this weekend. Its another fairly large tutorial that covers:<ul><li>Error Handling</li><li>Exception Handling</li><li>IRs, IRQs, ISRs</li><li>Gates: Traps, Interrupts, Tasks</li><li>IDTs and IVTs</li><li>IDTR processor register</li><li>LIDT and SIDT instructions</li><li>FLIHs and SLIHs</li><li>How interrupts work, stack, error codes</li><li>Developing a kernel panic error screen. ie, BSoD</li></ul>The tutorial itself is now completed. The demo should be completed either today or tomorrow, and will be uploaded with the tutorial.

After this tutorial, we should no onger see triple faults, and will be able to re-enable interrupts in protected mode.

Its going to be fun...

*edit: Fixed formatting

[juFo]

nice

[pathos]

Any news on when the demo will be up?

[Mike]

Any news on when the demo will be up?

I was hoping alot sooner, but we ran into a pretty nasty bug in the kernel that prevented us to continue.

The problem was with random instructions getting executed before the kernel do to global data being placed by MSVC++ before our entry point (but still at base 1MB). This caused odd global and static variable issues as it would cause the kernel to crash, before it even gets executed.

Here is the new Stage 3 for the stage 2 bootloader that should fix this, and possible future problems. All tutorials will be updated with this, and it seems to execute the entry routine flawlessly without error. ...And, of course, fixes the above problem

Code: Select all

	;---------------------------------------;
	;   Execute Kernel			;
	;---------------------------------------;

	mov	ebx, [0x100000+60]		; e_lfanew is a 4 byte offset address of the PE header; it is 60th byte.
	add	ebx, 0x100000			; Add base address. EBX now points to file sig (PE00)

	; jump over to optional header (Although it isnt optional o.0 )

	add	ebx, 24
	mov	eax, [ebx]			; _IMAGE_FILE_HEADER is 20 bytes + size of sig (4 bytes)

	add	ebx, 20				; address of entry point

	mov	ebp, dword [ebx]	; get entry point offset in code section	
	add ebp, 0x100000		; add image base

	jmp	ebp					; Execute Kernel

[pathos]

Thanks for the update =)

[Mike]

Thanks for the update =)

The next demo will be up soon. It is fairly complex at the moment as it abstracts hardware dependencies behind the HAL, installs a new GDT for the HAL/Kernel to manage, and will, of course, be setting up a good IDT interface as well for the kernel to use.

We are able to set a new gdt without any need for far jumping, so we can do everything using inline assembly.

I will be covering the code a little bit in the tutorial when it is updated, but most of it should not be too hard. It (Hopefully) will be uploaded within the next week or so.

[Mike]

The idt interface I am developing is pretty cool. It allows us to register our own callback handlers that are called automatically whenever an interrupt is fired.

Because the idt implementation also installs its own default handlers, we will only need to install our own handlers when needed. Any other INT that is generated that we have not set a handler for will be handled by the idt code automatically.

Ill explain how everything works in the tutorial...

[Mike]

The demo is now planned to be uploaded this weekend. Everything is good, we are now finalizing the demo.

[pathos]

The demo is now planned to be uploaded this weekend. Everything is good, we are now finalizing the demo.

Awesome. I look forward to it.

[dev]

The demo is now planned to be uploaded this weekend. Everything is good, we are now finalizing the demo.

How's the demo coming along?

[Mike]

The demo is now planned to be uploaded this weekend. Everything is good, we are now finalizing the demo.

How's the demo coming along?

Everything is already completed. I have not had much time this week to upload it Thanks to the weekend, it will be up tomorrow.

The next tutorial in the main series (Tutorial 16) integrates the 8259A PIC and 8253 PIT into the HAL. Because we are handling hardware interrupts in the next demo, we may also create a simple debugging command shell. We shall see...

Tutorial 17, We are thinking about implementing memory management, and programming the MMU, paging, perhaps loading the kernel to a 3GB virtual address space. We are still deciding everything though.

Cant wait 'til tomorrow

[pathos]

I've been busy the past few weeks with work and other projects, but I finally got a chance to dip into the latest demo this morning and check it out.

Everything's looking good, and I can't wait to handle hardware interrupts in the next demo!

[pathos]

Two quick questions.

First, when I go and write my own IRs, is there a way to get the address where the exception occured so I can display it with my handler?

Second, with the Tutorial 15 setup, I remapped my PIC, but my hardware interrupts are only firing once. Any thoughts why?

[Mike]

First, when I go and write my own IRs, is there a way to get the address where the exception occured so I can display it with my handler?

Sometimes the processor will push cs:eip on the stack when the exception fires. This depends on the exception, though. (Fault handlers are not guaranteed to push anything on the stack as the software is not expected to continue.)

Under the section Inside of our interrupt handler contains the basic stack frame when the interrupt is fired. Just offset into esp to get the information you need.

For an example, assuming the INT pushes an error code, offset 4 bytes into esp to get eip:

Code: Select all

; get eip of faulting instruction
mov  eax, dword [esp+4]

; stores faulting instruction opcode into eax
mov  edx, dword [eax]

(Hm... That stack frame does not include everything pushed by the cpu. I will see if I can add to that section)

Second, with the Tutorial 15 setup, I remapped my PIC, but my hardware interrupts are only firing once. Any thoughts why?

Hm... We might need to see how you have set everything up to answer that one. I assume you enabled hardware interrupts (sti instruction)?

What hardware interrupts have you tried?

[pathos]

Hm... We might need to see how you have set everything up to answer that one. I assume you enabled hardware interrupts (sti instruction)?

What hardware interrupts have you tried?

Thanks for the reply. The interrupts I have tried is 0 and 1 for the timer and the keyboard. The keyboard never fires, because the timer goes first, and then they all stop. However, I disabled all IRQs once except the one for the keyboard, and then it let me hit one key, then they all stopped.

Yes, I did use sti.

I don't have my code on this computer, but all it is is tutorial 15 + the information from your PIC tutorial to remap the PIC + writing the timer handler and the keyboard handler to IRs 32 and 33. My timer and keyboard code isn't the problem though because I tried setting the handlers to just a simple handler to print some text, and it still only triggers once.

[edit]
I'll try to give a bit more information.
After the HAL is initialized, I remap the PIC, then set the the timer and keyboard to their respective IRs, then I use sti. I commented out the asm code in kmain() before "for(;; );" because it was clearing interrupts and I didn't know if that was the problem. I've moved sti around to see if that helped (like before I set the handlers), but still no luck.

[edit x2]
As it turns out, this is affecting all my interrupts. For example, I forced a divide by zero exception. The handler fired. Then I tried another one right behind it, and the handler didn't fire. At first I thought maybe the system was halting after each interrupts, but I placed some DebugPrintf messages after where I forced the exception, and they displayed. So it seems my interrupts are getting disabled all together.

[edit x3]
Just wanted to point out one more thing. When I use geninterrupt(0), it takes me to the default handler; however, if I use _asm int 0, it takes me to my interrupt 0 handler.

[edit x4]
This pertains to the geninterrupt problem. It works (as in, it triggers the right handler), but immediately after it generates an invalid opcode exception.

[edit x5]
Hardware interrupt problem solved. I put "_asm cli;" at the beginning of my handler and "outportb(0x20,0x20); _asm sti;" at the end, and it works now. However, I'm still having an issue with firing the same software interrupt back-to-back.