[solved] GDT or IDT first?

[newbieg]

I started out trying to install my gdt as soon as possible in my development goals. It has not gone so well. I have found five or six tutorials, looked at about as many people's implementations, and read whatever sections of the intel manual that came recommended for the topic. No matter how I tweak my code, I keep getting triple faulted when I try to run in qemu.

1) I have decided to start working on my IDT instead to try and catch whatever exceptions are being thrown (still incomplete). I noticed that those tutorials and implementations that I've looked through so far have all installed the IDT directly after the GDT. Is there any reason that installing the IDT first is not recommended?

2) If you have time to peak at my code I'd appreciate it: https://github.com/newbieg/LimbOS
The triple fault occurs in boot.s, gdt_flush: after lgdt when I try to actually clear the registers. I figure that lgdt might not be discerning enough to detect if my C code is incorrect, so the real problem is likely still in src/gdt.c

[~]

The GDT is first. Without it you cannot enter Protected Mode and use a proper IDT.

Look at the kernel I've made. It contains several examples of GDT to set up Unreal Mode and Protected Mode for a kernel, also an example of IDT. They are very well documented:


Here you can get the code:
BOOTCFG__v2017-06-16.zip


I consider it to be very simple code. I have repeatedly cleaned up the code from many tutorials, improved it, documented better and packed in a reusable way, so you will probably find it useful to understand other basic tutorials and manuals.


If you want me to explain something or the GDT to you just tell me.

Just start by telling me what you understand exactly about the GDT and I can correct or complete it.

[LtG]

Have you tried the wiki?
http://wiki.osdev.org/GDT_Tutorial

Also, if you haven't yet, use gdb to debug your OS, instructions for that can also be found from wiki.. Don't be scared of gdb/debugging, you'll need to learn it anyway...

[bzt]

I figure that lgdt might not be discerning enough to detect if my C code is incorrect, so the real problem is likely still in src/gdt.c

Hi, first of all, your gdt struct doesn't seem correct. Second, you haven't cleared interrupts before you call your C code. Third, you don't have to mess with C here, simply store your gdt as data in asm, load it before you jump to C, and forget about it! Here's how I do it:

Code: Select all

            cli
            cld
            lgdt        [GDT_value]
            jmp         CODE_PROT:1f
1:          mov         ax, DATA_PROT
            mov         ds, ax
            mov         es, ax
            mov         fs, ax
            mov         gs, ax
            mov         ss, ax
            mov         esp, stack_top
            call        kernel_main

And my gdt table is here:
https://github.com/bztsrc/osz/blob/mast ... .asm#L1628
Here I've precalculated the entries I need, and I don't generate it with code.

I assume this gdt will just work fine for you. The selectors for it:
10h - data segment
20h - selects 16 bit code for unreal or v86 mode
30h - protected mode code segment
40h - protected mode TSS. Not used in my bootloader, but some emulators requires it anyway.

A little homework: my examples are in intel assembly, you'll have to convert them to AT&T syntax.

[newbieg]

Thank you all, I wasn't expecting such quick replies. You've all pointed me in what feels like good directions, thank you so much. I'll get back here when I make progress.

I do have to mention a failing on my part which is that I just started learning assembly; while implementing the gdt entirely in assembly is going to be my eventual route, I'm likely to leave that until this fall when I start college classes on assembly. I'm very grateful for the link to your code, and I'll be studying them closely.

[iansjack]

I'd say neither GDT nor IDT first. First improve your assembler skill. Until you are up to speed there you will find it nearly impossible to debug this sort of problem.

[newbieg]

Yeah, I understand that in OS development a bit of ignorance spreads a long way. I am trying to learn assembly on-the-go/crash-course style. It does mean that there are things that I miss along the way but I am taking my time and learning from my mistakes. I'm hoping that the classes this fall will also help me pick up the pieces.

So I got the GDT to the point of not-triple-faulting. Huzzah!
My current IDT implementation leaves a lot to be desired, so I'm going to disappear back into the intel manuals for a while. I wanted to thank everyone again for the help.

The problem was in the C code, but closer than I expected, In gdt_flush I was passing the argument for the gdt_ptr as the struct object itself. Apparently I was supposed to pass an int containing the address of the gdt_ptr instead: http://www.jamesmolloy.co.uk/tutorial_h ... 20IDT.html

[ggodw000]

i ended up doing my own video and file system driver before attempting idt.