OSDev.org

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 The problem with this code is that it causes a triple fault.
By basic debugging I found out it's the 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?

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.

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.

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

Artlav wrote: Are you sure your GDT is correct and loaded?

Yes, it is.

Octocontrabass wrote: 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

alexfru wrote: 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.

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.

StartOS wrote: 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.

StartOS wrote: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.

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. 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.

onlyonemac wrote: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.

onlyonemac wrote: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?

onlyonemac wrote: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.

iansjack wrote: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.

Combuster wrote: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.

onlyonemac wrote: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.

onlyonemac wrote: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.

onlyonemac wrote: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.