Problem with optimisations

[Steve the Pirate]

I'm having a bit of a problem with optimisations in my kernel. As far as I can tell, everything works as expected when you don't specify an optimisation level in the C flags. It also works with -O1 and -O3 (if you don't enable multitasking, but I'll get to that later), but as soon as you tried -O2 or -Os you would get a general protection fault. Judging from the instruction pointer and the dissasembly of the kernel, the fault occurs in my common IRQ stub in isr.asm (which is based on bkernev and JamesM's tutorials). The problem is here, just after the C++ handler returns:

Code: Select all

call irq_handler
	
pop ebx ; reload the original data segment descriptor
mov ds, bx  ; <- EIP points to this line
mov es, bx
mov fs, bx
mov gs, bx

Does anyone have any idea of what's going wrong? Oddly, the PIT handler runs fine, but as soon as you hit a key (usually on the first keypress, although sometimes it takes up to four or five) it GPFs...

[AJ]

Hi,

I'm not sure what the exact problem is, but here are some debugging tips:

1) In all likelyhood, your stack has becomr trashed and you are GPF'ing because you are loading an invalid segment descriptor in to ds. Have a look at your register dump to confirm this.
2) If it takes a variable number of keypresses, the problem may not purely be in this ISR. Perhaps it only occurs in the keypress happens after the timer has fired a few times or whatever. Try disabling the timer for a bit to see if the ISR's are interfering with each other.
3) A different -O level will lead to the stack frame looking different (due to variables being stored in different ways). Check that you have initialised all your variables (local and global).

This type of bug is often tricky to tie down, so good luck! Remember that Bochs is your friend and if I think of anything else, I'll get back

Cheers,
Adam

[Steve the Pirate]

Thanks for the suggestions. I'll take a look when I have some time tomorrow and report back!

[Craze Frog]

You need to debug it yourself or post more code so we can debug it. We can't find the fault in irq_handler and called functions when we can't see them...
And better print the value of esp at various stages to see if it is what you expect.

[Steve the Pirate]

You need to debug it yourself or post more code so we can debug it. We can't find the fault in irq_handler and called functions when we can't see them...

I posted a link to the file that the problem is in, and if you want to see the whole source, the full tree is here.

And better print the value of esp at various stages to see if it is what you expect.

OK, I'll take a look at that.

[Craze Frog]

You need to debug it yourself or post more code so we can debug it. We can't find the fault in irq_handler and called functions when we can't see them...

I posted a link to the file that the problem is in

No, I can assure you that problem isn't in that file. It's the inside irq_handler or any functions called from irq_handler.

[cyr1x]

You probably forgot to put some "volatile" keywords in.

[Steve the Pirate]

No, I can assure you that problem isn't in that file. It's the inside irq_handler or any functions called from irq_handler.

I meant that that is the file that contains the last instruction executed (mov ds, bx) before the exception is raised. It's probably not the file that the problem is in - I suppose it's far more likley there is a problem with my stack.