Post deleted
Re: Problems reloading the GDT in long mode?
Hi.
Your code uses iretq, but you don't push CS and RFLAGS (iretq pops RIP, CS and RFLAGS).
Personally, I use retfq to reload CS (retfq pops RIP and CS).
Your code uses iretq, but you don't push CS and RFLAGS (iretq pops RIP, CS and RFLAGS).
Personally, I use retfq to reload CS (retfq pops RIP and CS).
Re: Problems reloading the GDT in long mode?
Post deleted
Last edited by rpio on Tue Aug 12, 2025 7:10 pm, edited 1 time in total.
Re: Problems reloading the GDT in long mode?
I'd suggest that you could profit from looking at the Intel (or AMD) Programmer's Manual.ngx wrote: But what are RFLAGs and how do I push them?
How do you reload with retfq, do you use it instead of iretq?
Re: Problems reloading the GDT in long mode?
You could also just perform a direct inter-segment jmp (even if it's functionally the same code segment) which would make the intent clearer than setting up a stack for a ret or iret.
e.g. (in AT&T syntax):
Also, and just IMO, I'd reset the code segment flow immediately after loading a new GDT, and then set the data segment registers. It's what you have to do to go into protected or long mode, so seems best to be consistent.
e.g. (in AT&T syntax):
Code: Select all
lgdt gdt64_ptr
jmp $CODE_SEG, $rejump_label
rejump_label:
[continue on]
Re: Problems reloading the GDT in long mode?
Post deleted
Last edited by rpio on Tue Aug 12, 2025 7:09 pm, edited 2 times in total.
Re: Problems reloading the GDT in long mode?
Also called far jump.ngx wrote:Wow, never heard of inter-segment jump
Address. Well, "immediate" is what it means, but when applied to a label, you get the address.ngx wrote:(also does $ mean address or content of address?)
That was probably a word salad problem, but I'm guessing he meant that you have to reload your segment registers immediately after loading a new GDT. I concur. If you don't, you are just asking for something to at some point push an invalid segment descriptor to stack, and then crash when it's loaded back.ngx wrote:What do you mean by "reset code segment flow and data segment registers"?
For NASM, the syntax isngx wrote:I added inter-segment jump, please correct me if I forgot something or got something wrong:
Code: Select all
jmp 8:.reload_registersCarpe diem!
Re: Problems reloading the GDT in long mode?
AT&T and Intel syntax do everything backwards from each other.ngx wrote:Wow, never heard of inter-segment jump(also does $ mean address or content of address?)
AT&T "$label" is the same as Intel "label" (address of label)
AT&T "label" is the same as Intel "[label]" (content of label)
It just means reloading the CS register and the hidden portion of the register behind it. If you change your GDT, you need to make sure it's using the correct values from the updated GDT. This is why you have to perform a jump immediately after entering protected mode or long mode. You can't load CS directly, so you have to perform a jump or a ret.ngx wrote:What do you mean by "reset code segment flow and data segment registers"?
In your case, you may not have actually changed any relevant settings in the GDT, you're just pointing to the same GDT (or a copy of it) using a different linear address. Still, it's a good idea to reload CS, just to be on the safe side.
In most cases, you probably won't change the GDT after you finish booting. You need kernel code and data segments, eventually user code and data segments, and a TSS per CPU. Once you have all that in place, you perform one last jump to load CS properly, and you're good. Then you can be reasonably assured that you're not going to trip over something later as a result of the CPU holding older values from the GDT that was updated mid-boot.
Update: just saw nullplan's post. Yeah, sorry, "reset code segment flow" is just sort of my own word salad. It means what I said above, you've changed the GDT, so you want to be sure you're executing from the correct code segment, with all the correct settings, so you do a jump.
Re: Problems reloading the GDT in long mode?
Post deleted
Last edited by rpio on Tue Aug 12, 2025 7:09 pm, edited 1 time in total.
Re: Problems reloading the GDT in long mode?
Just use retfq, no need for iretq:
Code: Select all
pushq $0x08
pushq $label
retfq
label:
...
Re: Problems reloading the GDT in long mode?
Oops, sorry, yes, that's right. My mind completely overlooked the "already in long mode" part. Sheesh, where's the coffee.ngx wrote:Oh, if an inter segment jump is a far jump then I can't use it as I am in long mode where it is unavailable.
Then yes, you would push a code segment selector and address on the stack and do a retq. There's no need for iretq because you don't need to update any flags. It's probably better if you don't in case you accidentally enable interrupts before you're ready.
However, if you're SURE that you haven't modified your GDT, you can probably get away with not jumping. It's perhaps not good practice, but I do it when I switch from low memory to high mapped memory. I do an lgdt of exactly the same GDT at a different linear address. I know I haven't modified it in the meantime.
Re: Problems reloading the GDT in long mode?
Post deleted
Last edited by rpio on Tue Aug 12, 2025 7:08 pm, edited 1 time in total.
Re: Problems reloading the GDT in long mode?
Post deleted
Last edited by rpio on Tue Aug 12, 2025 7:01 pm, edited 2 times in total.
Re: Problems reloading the GDT in long mode?
Why don't you try both?ngx wrote:Should I use retq or retfq?
Why don't you try to determine the difference between the two to answer your question?
Why don't you read the manual?
Why don't you look at existing code that does what you need?
We are not here to spoon-feed you...
Re: Problems reloading the GDT in long mode?
Post deleted
Last edited by rpio on Tue Aug 12, 2025 7:02 pm, edited 1 time in total.




