3

I am creating an OS for the x86 processor, and have a program executing in user space (with paging enabled). Right before the program goes to make a syscall ('int $0x80'), the IDTR points to my IDT, and the entry for 0x80 points correctly to my the function I would like to have executed. In gdb, after an 'si', the processor ends up at address 0xe05b with the IDTR completely cleared (set to 0).

Note that before entering user space, the 'int $0x80' call works perfectly, it gets to my function call. After executing an artificial iret to get to userspace, the next 'int $0x80' causes this strange behavior.

If it helps, this all started happening after I made changes to my filesystem code, but I don't see where that could have anything to do with the IDTR.

It also seeems to clear every other register, including the stack, data, and code selector. Like it's some kind of panic

Does anyone know what could cause the processor to do this?

Thanks in advance!

Noah
  • 1,608
  • 15
  • 31

2 Answers2

2

I had the same exact problem and I corrected it by changing the ss0 value in my TSS when executing the process. Your esp0 value could also be wrong, but ss0 should be the Kernel DS value 0x18. Set ss0 to 0x18 when halting the process as well. As for esp0, it should be the esp you are leaving in execute (all I know at this time).

Branden
  • 21
  • 3
  • Welcome to _StackOverflow_, you might want to read [how to post an answer](http://stackoverflow.com/help/how-to-answer) before doing so. Consider taking the time to format your answer to be easily understood by readers. – Nacho Apr 21 '16 at 20:42
1

I'm going to assume that you're debugging under bochs. It looks like what is happening is that you are triple faulting the CPU which is causing it to reboot. f000:e05b is the address that the debugger breaks at in the BIOS when bochs starts up.

What is probably happening is that your IDT is invalid in some way which prevents the interrupt from being delivered from user mode. This then causes some other exception to be raised (possibly a general protection fault or double fault exception). If the IDT for that exception is not valid, then the CPU gives up and triple faults, which it handles by resetting itself.

You should check that your IDT is valid for calling through from user mode.

Stewart
  • 3,978
  • 17
  • 20