CODEWITHSUNDEEP
ckernelinterrupt-handlingosdev
Edmond
Edmond

Reputation: 173

strange behaviour in interrupt handler

I am currently developing a kernel and run into a mysterious problem when implementing system call. I write the 0x80th interrupt handler like this: 

sys_call_s:
    pushad
    call sys_call
    popad
    iret

"sys_call" is the name of the C function that do the real work. The problem is: I got a triple fault when executing the next instruction of "int 0x80". For example, I got a fault when executing the third line of the program below and finally bochs will reset itself.

abc: mov eax,0              ; 0 means system call get_pid()
     int 0x80
     mov [pid_father],eax   ; this is the instruction caused bochs to triple fault
     mov eax,1              ; 1: fork()
     int 0x80
     jmp $

pid_father:  dd 0

Even more strangly, when I substitute the "iret" instruction with "ret", the program works fine and spin itself at "jmp $".

Does anyone have any idea why I got this problem?

[edit] Now I think this problem is caused by the wrong address of the stack pointer. I have maped a page for this process, the physical address of this page is 0x401000, linear address is 0x800000(8M). I have set the stack pointer of this process to 0x800ff0, but each time I use "print-stack" command in bochs the output is: "physical address not available for linear 0x00801000". How can I fix it?

[edit] Now I found that I can't access data in this process. for example when I place "mov [pid_father],eax" before "int 0x80", bochs resets itself. why this happened?

Upvotes: 1

Views: 639

Answers (1)

Stewart
Stewart

Reputation: 4036

I think you need to show the contents of your GDT and DS registers and paging tables. If you are seeing the triple fault on that line without any of the rest of the code, then that would imply that the access to [pid_father] is the problem. The data segment is invalid, or the page is invalid or marked read-only, which is causing a GPF or page fault exception. The GPF or page fault exception is failing (possibly for the same reason, or a different one), which is causing a double fault exception, which is again failing causing the CPU to triple fault and reset.

Bochs is usually pretty good (from memory) at printing out why it faulted. You may want to scroll up the history a little and look for the first exception that was raised.

Upvotes: 1

Related Questions