pitticks, the forbidden variable [solved]

[cr2]

I did set FS and GS to 0x10.

P.S. neon, your tutorials helped me in the development of my bootloader

[neon]

I did set FS and GS to 0x10.

Hm... Your bochs output says otherwise... Is your Bochs log different then the one you posted? If so, can you post it?

We may also still need that disassembly...

P.S. neon, your tutorials helped me in the development of my bootloader

I'm am glad they helped I am going to be uploading a new version of it soon do to 4 bugs being fixed (As well as making the kernel a real 32 bit EXE program)

[cr2]

I tried setting FS, GS to 0x10 inside the PIT IRQ and it still failed. FS, GS weren't 0x10 when bochs panic-ed.

[cr2]

pitticks++ is screwing with the values in FS and GS. I commented out pitticks++, and the bochs log stated that FS, GS were 0x10.

[neon]

Thats interesting...

The only way we can be certain to what your interrupt handler is doing is if you post a disassembly of it.

Or, if you want, post your project here (or email me) so I can take a closer look at it.

[cr2]

I tried replacing pitticks++ with:

Code: Select all

_asm
{
    mov eax, [pitticks]
    inc eax
    mov [pitticks], eax
}

...and it failed.

P.S. I am using Visual C++ 2008

P.P.S. I am going to see if I can disassemble this function (I have no idea where it is at in my kernel's executable file)

[neon]

You should be able to have the compiler output the assembly. Just make sure you are building with Assembly With Source Code (/FAs) and look for the assembled file.

[cr2]

Got it(the semi-asm code)!

Code: Select all

?pit_irq@@YAXXZ PROC					; pit_irq, COMDAT

; 21   : {

  00000	53		 push	 ebx
  00001	56		 push	 esi
  00002	57		 push	 edi

; 22   : 	_asm pushad

  00003	60		 pushad

; 23   : 	pitticks++;

  00004	ff 05 00 00 00
	00		 inc	 DWORD PTR ?pitticks@@3IA ; pitticks

; 24   : 	outportb (0x20, 0x20);

  0000a	6a 20		 push	 32			; 00000020H
  0000c	6a 20		 push	 32			; 00000020H
  0000e	e8 00 00 00 00	 call	 ?outportb@@YGXGE@Z	; outportb

; 25   : 	_asm popad

  00013	61		 popad

; 26   : 	_asm iretd

  00014	cf		 iretd

; 27   : }

[neon]

Alright... You will first be needing to fix up the stack frame. Notice how MSVC pushes some values on the stack but it is never popped off?

Try this:

Code: Select all

void __declspec(naked) _cdecl pit_irq()
{
   _asm add esp, 12
   _asm pushad
   pitticks++;
   outportb (0x20, 0x20);
   _asm popad
   _asm iretd
}

I am unsure why MSVC is doing this as the routine is naked; I cannot be sure without knowing your project settings.

[cr2]

MSVC++: "Close, but no cigar!"

Nope, doesn't work.

Just to let you now, even pitticks = 0 GPFs.

[neon]

You still need to answer the other question: Does it only #GPF when accessing the variable from within the interrupt handler? ...Or from anywhere?

You may need to run this in the Bochs debugger to see exactally what is going on.

Just put a CLI+HLT instructions in your interrupt handler. Run the debugger and use the continue command (c). It will stop at your HLT instruction. use ctrl+c to break into the debugger and you will be inside of your interrupt handler. Hit s to single step and h for help.

[cr2]

Does it only #GPF when accessing the variable from within the interrupt handler? ...Or from anywhere?

from anywhere

[cr2]

it stops before the cli&hlt(which is prior to the pitticks++), but when I comment out the pitticks++, it works

[neon]

it stops before the cli&hlt(which is prior to the pitticks++), but when I comment out the pitticks++, it works

It is supposed to stop. That is when you need to break into the debugger (CTRL+C) and single step to see what the next couple of instructions are what you expect them to be. Using your linker map, you can get the location of your pitticks variable.

When I initialize the GDT it GPFs.
I didn't add it as a class member (it was(like my PIT IRQ) part of _pit, but I later removed it from the class to solve another error that came up).

You should be able to do both without any problems. What is the "other error"?

[cr2]

You should be able to do both without any problems. What is the "other error"?

MSVC++ didn't allow me to set a class member as a handler in the IDT.