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/osloader-dev/osloader/osloader.asmIt 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:
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:
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...