Page 1 of 1

[Solved] an issuse about GP exception in infinte loop

Posted: Fri May 01, 2020 10:31 pm
by whereware
I am learning things about os dev and I write a simple loader promgram.

It loads gdt, enters protected mode and runs inito a infinte loop.

The problem is

when program runs into the infinte loop like "jmp $"...

it causes GP exception, then again, finally I get a triple fault.

but if I enter "si" continusly in GDB to run "jmp $"

it runs as expected...

are there any mechanisms in processor to prevent this kind of inf loop?

or it is just fault of my code.

thanks in advance!

Re: an issuse about GP exception in infinte loop

Posted: Sat May 02, 2020 12:52 am
by iansjack
It would help if you posted a link to your code (in an online repository - don't just paste all the code here) and detailed the exact steps that you followed in gdb.

On the face of it, if a program causes a GPF when run it will do the same when running under gdb.

Re: an issuse about GP exception in infinte loop

Posted: Sat May 02, 2020 4:24 am
by whereware
iansjack wrote:It would help if you posted a link to your code (in an online repository - don't just paste all the code here) and detailed the exact steps that you followed in gdb.

On the face of it, if a program causes a GPF when run it will do the same when running under gdb.
Thank you for your reply!

Here is the code:

https://github.com/D0ot/dotkernel/blob/ ... loader.asm

It would cause some GPFs and finally a tripple fault with QEMU + gdb.

Steps:
(type in gdb)
1. "b _flush" , _flush is a label in the file above , at line 38
2. "si" "si" , type many si, it will reach the "jmp $"
3. "si", it runs "jmp $" well. no GPF
4. "c", QEMU closes(i used the option "--no-reboot" when lanuching QEMU) and leaves log saying :

Code: Select all

check_exception old: 0xffffffff new 0xd
     1: v=0d e=0042 i=0 cpl=0 IP=0008:00007e38 pc=00007e38 SP=0010:00007c00 env->regs[R_EAX]=d88e0010
...
check_exception old: 0xd new 0xd
     2: v=08 e=0000 i=0 cpl=0 IP=0008:00007e38 pc=00007e38 SP=0010:00007c00 env->regs[R_EAX]=d88e0010
...
check_exception old: 0x8 new 0xd
Triple fault
disassembly outpu by objdump:
"i686-elf-objdump -d -M intel -M i386 osloader.elf"

Code: Select all

  00007e29 <_flush>:
      7e29:       66 b8 10 00             mov    ax,0x10
      7e2d:       8e d8                   mov    ds,eax
      7e2f:       8e c0                   mov    es,eax
      7e31:       8e d0                   mov    ss,eax
      7e33:       bc 00 7c 00 00          mov    esp,0x7c00
      7e38:       eb fe                   jmp    7e38 <_flush+0xf>
I don't know why...

Re: an issuse about GP exception in infinte loop

Posted: Sat May 02, 2020 4:42 am
by Octocontrabass
whereware wrote:

Code: Select all

e=0042
This means the IDT entry for INT 0x08 (IRQ0) is invalid.

Perhaps you should disable interrupts before switching to protected mode.

Re: an issuse about GP exception in infinte loop

Posted: Sat May 02, 2020 4:56 am
by iansjack
As exception 0x08 is a double fault, I don't think that is the root cause. But, as there is no IDT to be valid or invalid, the root cause is obviously some interrupt or exception occurring. Could be the timer interrupt and you just didn't single-step enough times to hit it.

As already said, either disable interrupts or create a valid IDT with valid handlers.

Re: an issuse about GP exception in infinte loop

Posted: Sat May 02, 2020 5:19 am
by whereware
Octocontrabass wrote:
whereware wrote:

Code: Select all

e=0042
This means the IDT entry for INT 0x08 (IRQ0) is invalid.

Perhaps you should disable interrupts before switching to protected mode.
Thanks!

I am just a beginner and I don't know the meaning of that "e=xxx". :D thanks again. hahaha

Re: an issuse about GP exception in infinte loop

Posted: Sat May 02, 2020 5:28 am
by whereware
iansjack wrote:As exception 0x08 is a double fault, I don't think that is the root cause. But, as there is no IDT to be valid or invalid, the root cause is obviously some interrupt or exception occurring. Could be the timer interrupt and you just didn't single-step enough times to hit it.

As already said, either disable interrupts or create a valid IDT with valid handlers.
Thanks!

It could be a best practice? Maybe I should read code of someone else. hahaha. Thanks again!