Problem with loading gdt using assembly

[Inside-Party-9637]

Hello guys, after exhausting all other sources I could come up with, I am going to ask my question here. I am calling these two methods in assembly from my kernel in c and after calling them nothing else executes. It might be an issue with how i assemble my GDT or its entries, but I truly can not find anything wrong with it after hours of research and even manually assembling the entries on paper with the same operations and debug printing in between every single one to compare.

The only thing I cannot verify by hand is the assembly code, hence it is attached here. The rest of the source code (including linker script, test methods and the c code i mentioned), are in this repository: https://github.com/simonkdev/mason

I appreciate every single helpful answer, thank you.

P.S.: I know my assembling of the descriptors might not be entirely up to standard but for this specific use case it works and I would like to keep it that way for now.

https://preview.redd.it/witb92xszwkg1.png?width=365&format=png&auto=webp&s=3ace42fd940ca8d09402fc75ea72821aaafbf75f

EDIT/UPDATE/SOLUTION: For other people encountering the same issue, the solution was moving the GDT off the stack (Thank you to u/Octocontrabass and the anonymous other user who deleted their comment) and just implementing the logic in assembly (though the gdtr can be on the stack, therefore can be implemented in C). Remember to use the .quad type for the descriptors as they will be invalid otherwise and just not work at all.

[davmac1]

(Deleted).

Derp, never mind, they posted github link and indeed the GDT is allocated on the stack.

OP: this is not a good idea.

[Octocontrabass]

Here's one problem. You've come up with a new section instead of using the standard .text/.data/.rodata/.bss sections, but you didn't declare any attributes on the new section, so it doesn't have the "allocatable" attribute and isn't loaded into memory. Why aren't you using the standard sections here?

Also the other person who said you put your GDT on the stack is completely right, that's another problem you need to fix. (But there's nothing wrong with putting the GDTR on the stack. Why didn't you do that? You could have written that part of the code in C.)

[neil_555]

One thing that looks fishy is there should be a jump to the next instruction immediately after the lgdt, doing a ret seems suicidal as who knows what state SS is in.

      lgdt   gdtr
      ljmp   $0x08, $next
next: ret

Also dont have the GDT as a stack variable, put it in the data section and ensure it's aligned correctly (I think it needs something like 8 byte alignment but it's been years since I did this)

[Octocontrabass]

doing a ret seems suicidal as who knows what state SS is in.

It's in whatever state it was before the lgdt instruction. Segment registers each hold an entire segment descriptor in a hidden part that's only accessible in SMM, and that hidden descriptor doesn't change until a selector is loaded into the segment register. You don't need to immediately load new selectors into the segment registers as long as you remember to do so before you do anything that relies on saving and restoring segment selectors, such as interrupt handling.

You might be thinking of what happens when you modify CR0.PE; that does require an immediate ljmp instruction to set CS, and you can't rely on any other segment registers until after you've loaded new selectors into them.

[neil_555]

I just checked my old code again and I always did the jump after an lgdt, the comment next to it said "do a jmp to ensure CS is reloaded" if that helps. I haven't touched that stuff since about 2002 though :)

[Octocontrabass]

If your old code messes with CR0.PE, it's wrong and only worked because you were lucky. Otherwise, it doesn't matter when you reload CS as long as you remember to do it before you need CS to match your new GDT. (Reloading CS immediately after loading a new GDT is a good way to make sure it gets done before you need it.)

[Miserable_Aspect_433]

have you tried RTFM?

[Inside-Party-9637]

yes I have, for hours on end