Keyboard interrupt triggers a GPF in pmode

[hakware]

I compile everything from scratch, and use qemu for emulation. Mostly I just boot up into my PII machine for testing XANA (since I need to write to a floppy anyway for the image -- no loopback).

[hakware]

Yeah, tried the leave thing, and pushing/popping all registers. Just uploaded the newest version tarball, in case I'm doing it wrong and someone can catch it. The KB handler code is in src/klib/Stdin.d .

[B.E]

Here's what assembly the compiler produces:

Code: Select all

 1360              	KB_handle:
 1361              	.LFB4:
 1362 01f1 83EC0C   		subl	$12, %esp ; << note this line
 1363              	.LCFI8:
 1364              	#APP
 1365 01f4 FA       		cli	
 1366 01f5 50       		pushl	%eax
 1367 01f6 53       		pushl	%ebx
 1368 01f7 51       		pushl	%ecx
 1369 01f8 52       		pushl	%edx
 1370 01f9 56       		pushl	%esi
 1371 01fa 57       		pushl	%edi
 1372 01fb 54       		pushl	%esp
 1373              	#NO_APP
 1374 01fc E8FCFFFF 		call	_D5Stdin7read_KBFZa
 1374      FF
 1375 0201 88C2     		movb	%al, %dl
 1376 0203 FF050000 		incl	_D5Stdin10KB_BUFFLENk
 1376      0000
 1377 0209 A1000000 		movl	_D5Stdin10KB_BUFFLENk, %eax
 1377      00
 1378 020e 88140500 		movb	%dl, _D5Stdin9KB_BUFFERG1024a(,%eax)
 1378      000000
 1379 0215 83EC0C   		subl	$12, %esp
 1380              	.LCFI9:
 1381 0218 A1000000 		movl	_D5Stdin10KB_BUFFLENk, %eax
 1381      00
 1382 021d 0FB60405 		movzbl	_D5Stdin9KB_BUFFERG1024a(,%eax), %eax
 1382      00000000 
 1383 0225 50       		pushl	%eax
 1384              	.LCFI10:
 1385 0226 E8FCFFFF 		call	_D3std5stdio4putcFaZv
 1385      FF
 1386 022b 83C410   		addl	$16, %esp
 1387              	.LCFI11:
 1388 022e E8FCFFFF 		call	_D3pic3EOIFZv
 1388      FF
 1389              	#APP
 1390 0233 5C       		popl	%esp
 1391 0234 5F       		popl	%edi
 1392 0235 5E       		popl	%esi
 1393 0236 5A       		popl	%edx
 1394 0237 59       		popl	%ecx
 1395 0238 5B       		popl	%ebx
 1396 0239 58       		popl	%eax
 1397 023a C9       		leave	
 1398 023b 66CF     		iretw	
 1399              	#NO_APP
 1400 023d 83C40C   		addl	$12, %esp ; << also Note this line
 1401 0240 C3       		ret

Your stack pointer is in a different location to when it started. which means that when iret is executed, it's returning to a different location then where you started (which is causeing the GP).

There's two ways you can solve this: first (hack) is add "add esp, 12" before iret (but after you restore esp).

The other way is to use an assembly stub. For example (note: havn't tested it, but you get the idea).

Code: Select all

global IRQ1
extern KB_handle

IRQ1:
		pushad
		call KB_handle
		popad
		iret;

and in stdin

Code: Select all

static extern (C) void KB_handle () {
	KB_BUFFER[++KB_BUFFLEN]=read_KB();
	putc(KB_BUFFER[KB_BUFFLEN]);
	pic.EOI();
}
. . .
void init_KB (inout IDT i) {
	KB_BUFFLEN=0;
	i.set(IRQs.IRQ1, @IRQ1);
}

[hakware]

Unfortunately, the adding 12 thing didn't work (not sure why, but I'd rather not deal with it). I'm currently attempting the asm stub thing. Btw, thank you all (especially B.E and everyone else who has actually downloaded the code and looked) -- most of those things I would have never caught, and thankfully I got everything at least almost working, thanks to all of your help. I'm not new to OS dev, but I am a bit of a noob to it (I haven't ever gotten an OS to work to the point XANA has), and so I'm glad such a helpful place exists <3

[hakware]

Haha! It works! :D:D:D

Thank you so much!