Problems with switching to new Code Segment

[StartOS]

I have my GDT kernel code segment at offset 0x08, with base 0x0 and limit 0xffffffff.
As said in the OSDEV Wiki GDT Tutorial I reload the Code&Data segments with new descriptors

Code: Select all

reloadSegments:
   ; Reload CS register containing code selector:
   JMP   0x08:reload_CS ; 0x08 points at the new code selector
   reload_CS:
   ; Reload data segment registers:
   MOV   AX, 0x10 ; 0x10 points at the new data selector
   MOV   DS, AX
   MOV   ES, AX
   MOV   FS, AX
   MOV   GS, AX
   MOV   SS, AX
   RET

The problem with this code is that it causes a triple fault.
By basic debugging I found out it's the

Code: Select all

JMP   0x08:reload_CS ; 

line that causes problems.
If my kernel code segment is the second entry in the GDT (the first one being null) what have could I done wrong that it does not work?

[Octocontrabass]

Instead of guessing, check the Bochs log. It's pretty good at telling you what you've done wrong, if you know how to read it.

[Artlav]

Are you sure your GDT is correct and loaded?
If you are running in Bochs debugger, you can use commands like info gdt to check that.

[alexfru]

GDTR is wrong (doesn't point to the GDT)
GDT[1] is wrong
Old cs.base ≠ new cs.base, which your subroutine, as written, expects

[StartOS]

Are you sure your GDT is correct and loaded?

Yes, it is.

Instead of guessing, check the Bochs log.

I currently use qemu because of its ability to load a kernel without a need to create a disk image.
I will consider switching to bochs in near future

GDTR is wrong (doesn't point to the GDT)
GDT[1] is wrong
Old cs.base ≠ new cs.base, which your subroutine, as written, expects

The GDT code alone works and doesn't crash anything.
It's the segment reloader.

[Octocontrabass]

The LGDT instruction does not validate the contents of the GDT or the GDTR. If either of those are wrong, you won't find out until you try to use your GDT.

[kzinti]

The GDT code alone works and doesn't crash anything.
It's the segment reloader.

There is no such thing as a "segment reloader". If your jmp instruction crashes, it's either because:

1) Your GDT is invalid / your GDT entry at offset 0x08 is invalid
2) Your jump offset (reload_CS) is invalid

(I am just repeating exactly what alexfru told you.)

I am afraid that not telling us what is in your GDT, not providing us with all your code and maintaining that there is nothing wrong with your GDT isn't going to allow us to help you very much.

[kzinti]

I currently use qemu because of its ability to load a kernel without a need to create a disk image.
I will consider switching to bochs in near future

Consider it now. Not using Bochs is blocking you. Takes the few minutes it takes to learn how to make a disk image.

[onlyonemac]

Short answer: You are not taking the base address of your code into account.

Long answer: The labels in your code are calculated relative to the start of the code. If your code is loaded at base address 0x00000000 then you're good to go, but most likely (hopefully) it isn't. You haven't specified where this code is being loaded so I'm going to assume it's a floppy disk boot sector in which case it's loaded at 0x00007C00. In that case, the JMP instruction needs to say

Code: Select all

JMP 0x0008:reload_cs+0x00007C00

. If you're loading at some other base address, you need to replace the 0x00007C00 with whatever the base address is.

Extra comments: People, it doesn't matter what test environment he's using. Take a look at his code before you start trying to "sell" your favourite emulator.

[Octocontrabass]

People, it doesn't matter what test environment he's using. Take a look at his code before you start trying to "sell" your favourite emulator.

We prefer to teach how to solve problems instead of giving the solution. Bochs is a better tool for figuring out this problem than Qemu.

[iansjack]

Extra comments: People, it doesn't matter what test environment he's using. Take a look at his code before you start trying to "sell" your favourite emulator.

So, having looked at his code can you give us a definitive answer as to what the problem is?

[Combuster]

You haven't specified where this code is being loaded so I'm going to assume it's a floppy disk boot sector (...)

Given the few rare details he did post, you're wrong (or he's been lying, but that's a different matter). Exercise for you to figure out why.

[onlyonemac]

So, having looked at his code can you give us a definitive answer as to what the problem is?

Without extra information, I cannot give a definitive answer. But at least I actually tried to suggest something useful, and didn't just tell him to use different testing software. I looked at the code and there appears to be an error which, without the source code or further details regarding how the code is loaded, cannot be verified further.

Given the few rare details he did post, you're wrong (or he's been lying, but that's a different matter). Exercise for you to figure out why.

No, you can figure out why. I rest my case.

EDIT: I bet you're going to say it's got something to do with a .ORG directive. Well guess what? Neither did he give us a .ORG directive nor did he tell us where the code is being loaded, so without that information I can't give him (or you) a better answer.

[kzinti]

Extra comments: People, it doesn't matter what test environment he's using. Take a look at his code before you start trying to "sell" your favourite emulator.

This isn't about preferences. Bochs has functionality that QEmu doesn't. Specifically, it has a debugger. That's very useful to debug problems.

But at least I actually tried to suggest something useful, and didn't just tell him to use different testing software.

So did alexfru and I. We listed what the problems could be and suggested using Bochs to sort it out.

[iansjack]

But at least I actually tried to suggest something useful, and didn't just tell him to use different testing software.

Possibly the most helpful answer that could be given.

there appears to be an error which, without the source code or further details regarding how the code is loaded, cannot be verified further

So not really very useful to suggest that we should read the (not provided) code.

It is probably, IMO, better to give the OP help as to how to debug the problem for himself rather than just making guesses based on little evidence.