OSDev.org

Posted: **Wed Feb 22, 2012 7:30 pm**

I'm having a problem tracking down the cause of a GPF in my code.

My GDT and IDT have to be perfect, I've checked them tens of times.

I know only bare rudimentary assembly and I am convinced that is where my problem is.

I install my GDT, IDT, set up ISR handlers from 0-31 and IRQ handlers for 32-47, then execute 'sti' and immediately I get the GPF.

Somehow, I believe a stack problem is being caused by my isr or irq stub handler.

Note that all isrs and irqs push a dummy error code if the cpu doesn't.

If I execute this code

Code: Select all

isr_common_stub:
pusha			
push gs
push fs
push es
push ds

mov ax, 0x10		; Load the kernel data segment descriptor;
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

mov eax, esp
push eax
mov eax, fault_handler
call eax
pop eax

; Commented out here, enabled in the next example
;call fault_handler
      
pop ds
pop es
pop fs
pop gs
      
popa
add esp, 8		; Cleans up the pushed error code and pushed ISR number
iret

This is my result:

General Protection Fault Exception
Error Code: 129
ds: 16
es: 1048592
fs: 16
gs: 16
edi: 128
esi: 179832
ebp: 1073144
esp: 1073096
ebx: 179488
edx: 142
ecs: 753664
eax: 47
int_no: 13
err_code: 129
epi: 1053168
cs: 8
eflags: 66050
esp: 1053395
ss: 1054748

However, whenever I change the way I call my fault handler by just doing a "call fault_handler",

Code: Select all

isr_common_stub:
pusha			
push gs
push fs
push es
push ds

mov ax, 0x10		; Load the kernel data segment descriptor;
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

; Commented out here, enabled in the previous example
;mov eax, esp
;push eax
;mov eax, fault_handler
;call eax
;pop eax

call fault_handler
      
pop ds
pop es
pop fs
pop gs
      
popa
add esp, 8		; Cleans up the pushed error code and pushed ISR number
iret

I get gibberish:

Unknown Interrupt!
ds: 40262597203
es: 40262597203
fs: 40262597203
gs: 40262597203
edi: 4026597029
esi: 4026591623
ebp: 40262597203
esp: 40262597203
ebx: 40262597203
edx: 40262597203
ecs: 4026593111
eax: 40262597203
int_no: 3221225779
err_code: 4026597203
eip: 4026595393
cs: 4026590206
eflags: 4026591033
esp: 4026595417
ss: 4026591278

I don't know enough about x86 to figure out what the root cause of this is.

Anyone have any ideas?

Posted: **Thu Feb 23, 2012 3:24 am**

What is the error code with the GPF ?

Posted: **Thu Feb 23, 2012 4:20 am**

That's because C functions expects arguments on the stack directly before the return address provided by the function call. The fault_handler function expects exactly one pointer, referencing the location of registers in memory. In the first case it's present (mov eax, esp; push eax;) in the second case, you forgot it and it will therefore use something else on the stack (in this case, DS) instead.

Posted: **Thu Feb 23, 2012 5:04 am**

I guess your fault handler expects some pointer to a structure containing register values. You push the stack pointer (which points to these values) in the first example, but not in the second. Try this instead:

Code: Select all

isr_common_stub:
pusha         
push gs
push fs
push es
push ds

mov ax, 0x10      ; Load the kernel data segment descriptor;
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

; Commented out here, enabled in the previous example
mov eax, esp
push eax
call fault_handler
pop eax
     
pop ds
pop es
pop fs
pop gs
     
popa
add esp, 8      ; Cleans up the pushed error code and pushed ISR number
iret

Posted: **Thu Feb 23, 2012 1:34 pm**

Combuster wrote:The fault_handler function expects exactly one pointer, referencing the location of registers in memory. In the first case it's present (mov eax, esp; push eax;) in the second case, you forgot it and it will therefore use something else on the stack (in this case, DS) instead.

Brilliant deduction. I can't believe I didn't notice this before. Coding in long stretches leads to a mushy brain.

gerryg400 wrote:What is the error code with the GPF ?

The error code is 129.
Which means 0000 0000 1000 0001
The ext flag is set, so of course what is happening is that immediately after executing 'sti', an irq fires, which would call an interrupt and set the ext flag.

The IDT flag is cleared so there's the segment index 16 is a GDT index.

I only have 3 entries in my GDT though, so why the hell is it trying to access index 16?
EDIT: I'm retarded once again. Byte index 16, not entry index 16.

EDIT:
That is the index of my data segment, where the execute bit of the access field for that entry is set to zero. Perhaps the processor is checking the data segment entry erroneously instead of the code segment entry when it tries to execute an irq handler?

Posted: **Thu Feb 23, 2012 2:34 pm**

Derpa derp, found the root cause of my GPF.

I set all the interrupt service routine kernel code segment selectors correctly to 0x08.
When I installed my irq handlers into the IDT, I set the code segment selector to 0x80.

Stupid errors that happen when you copy and paste code you don't understand.

Inevitably you spend 48 hours learning what you should have learned in the first place.

Posted: **Fri Feb 24, 2012 2:20 am**

mmurfin87 wrote:Stupid errors that happen when you copy and paste code you don't understand.

Inevitably you spend 48 hours learning what you should have learned in the first place.

A warm welcome to the Illuminati of OSDev. You have made your first step towards mastership. Now please go forth and help us in our quest of preaching to the unenlightened.

OSDev.org

Noob GPF Help [SOLVED]

Noob GPF Help [SOLVED]

Re: Noob GPF Help

Re: Noob GPF Help

Re: Noob GPF Help

Re: Noob GPF Help

Re: Noob GPF Help

Re: Noob GPF Help