OSDev.org
https://forum.osdev.org/

Crash after loading GDT and flushing registers
https://forum.osdev.org/viewtopic.php?f=1&t=52796
Page 2 of 2

Author:  nexos [ Tue Sep 14, 2021 1:38 pm ]
Post subject:  Re: Crash after loading GDT and flushing registers

You're still violating the ABI :) . You should be doing this:
Code:
mov edx, dword [esp+4]

Right now, you're accessing the function return address (not the first parameter) if you just did
Code:
pop edx

Author:  YDeeps1 [ Tue Sep 14, 2021 1:53 pm ]
Post subject:  Re: Crash after loading GDT and flushing registers

nexos wrote:
You're still violating the ABI :) . You should be doing this:
Code:
mov edx, dword [esp+4]

Right now, you're accessing the function return address (not the first parameter) if you just did
Code:
pop edx


I am aware! Popped was the wrong word to use :lol: I was still accessing the parameter; not the return address. Thanks anyways.

Author:  YDeeps1 [ Tue Sep 14, 2021 3:55 pm ]
Post subject:  Re: Crash after loading GDT and flushing registers

I have done a little more debugging and I found QEMU very helpful.

Debugging by launching the VM with the debug flag set to log interrupts, the first interrupt appears to be a general protection fault (0xd - 13):
Code:
check_exception old: 0xffffffff new 0xd
     0: v=0d e=0010 i=0 cpl=0 IP=0008:0010001b pc=0010001b SP=0010:00301fb4 env->regs[R_EAX]=00000010


Update - After sacrificing some of my sleep I have finally figured out the problem! My function which deals with split bits is incorrect and produces incorrect bits so I have converted my entry structure into a little bitfield and simply opted into hard coding the bits with a little assistance of a binary to hex converter and now my table works.

Code:
GDT DefaultGDT = {
    {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
    {0x8000, 0x0, 0x0, 0x9A, 0x0, 0xC, 0x0},
    {0x8000, 0x0, 0x0, 0x92, 0x0, 0xC, 0x0},
    {0x8000, 0x0, 0x0, 0xFA, 0x0, 0xC, 0x0},
    {0x8000, 0x0, 0x0, 0xF2, 0x0, 0xC, 0x0}
};


And have also fixed up my far jump with the help of the wiki.

Thank you everyone for your contributions!

Author:  Octocontrabass [ Tue Sep 14, 2021 7:28 pm ]
Post subject:  Re: Crash after loading GDT and flushing registers

YDeeps1 wrote:
I have also logged the address of the GDT offset + size table address (decimal 18874372) which matches up with the EDX register, removing some possibilities.

Why is this address 17 megabytes above the start of your kernel? How big is your kernel, anyway?

Author:  YDeeps1 [ Wed Sep 15, 2021 12:31 am ]
Post subject:  Re: Crash after loading GDT and flushing registers

Octocontrabass wrote:
YDeeps1 wrote:
I have also logged the address of the GDT offset + size table address (decimal 18874372) which matches up with the EDX register, removing some possibilities.

Why is this address 17 megabytes above the start of your kernel? How big is your kernel, anyway?


I was about to answer that. My kernel is actually only a few kilobytes maximum but to avoid any possibility such as my stack doing something to the GDT like accidentally overwriting it due to some other critical mistake I have instead stored it in my heap which I set to be about 20M above to remove this doubt.

Author:  Octocontrabass [ Wed Sep 15, 2021 8:49 am ]
Post subject:  Re: Crash after loading GDT and flushing registers

That's the address of your GDT descriptor, not your GDT. According to the register dump from earlier, your GDT lives in the .data section near your stack.

And anyway, you don't need the GDT descriptor after you've copied it into the GDTR with LGDT. You could allocate it on the stack instead.

Author:  nullplan [ Wed Sep 15, 2021 10:13 am ]
Post subject:  Re: Crash after loading GDT and flushing registers

Small function to load GDT with GDTR on stack:
Code:
;C interface: void load_gdt(const void *gdt, size_t sz);
global load_gdt
load_gdt:
  sub esp, 8
  mov eax, [esp+12]
  mov cx, [esp+16] ; if this exceeds 2 bytes, you have a problem, anyway
  dec cx
  mov [esp+4], eax
  mov [esp+2], cx
  lgdt [esp+2]
  add esp, 8
  ret

Page 2 of 2 All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/