X86 IDTR to clean up CPU and jump to EIP 0xe05b after "int $ 0x80"

I am building an OS for an x86 processor and have a program that runs in user space (with paging support). Right before the program goes to syscall ('int $ 0x80'), IDTR points to my IDT, and the entry for 0x80 points to my function that I would like to execute. In gdb, after "si", the processor ends at 0xe05b when the IDTR is completely cleared (set to 0).

Note that before the user space is entered, the 'int $ 0x80' call works fine, it jumps to my function call. After making an artificial jump to jump to user space, the next "int $ 0x80" causes this strange behavior.

If that helps, it all started after a change in my filesystem code, but I don't see where it could have anything to do with IDTR.

It also sees to clear every other register, including stacks, data, and code selector. As if some kind of panic

Does anyone know what can get the processor to do this?

Thanks in advance!

+3


source to share


2 answers


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

What is probably happening is that your IDT is incorrect, which prevents the interrupt from being delivered from user mode. This results in some other exception being thrown (perhaps a general protection error or a double error exception). If the IDT for this exception is invalid, the CPU crashes and triple faults, which it handles by rebooting itself.



You should check that your IDT is valid to be called from user mode.

+1


source


I had the same exact problem and fixed it by changing the ss0 value in my TSS while doing this process. The esp0 value may also be wrong, but ss0 must be the Kernel DS value 0x18. Set ss0 to 0x18 when the process stops. As far as esp0 is concerned, it should be esp which you leave in the middle of execution (everything I know at this time).



+1


source







All Articles