Error while implementing GDT.

[quiet]

Hi everyone. I am pretty new to osdev and started developing my first os by using meaty skeleton. After succesfully adding scrolling and cursor support to vga driver, i started to implement GDT. I read Intel manual and also used Writing Your Operating System From Scratch book. After i refreshed my knowledge on theory i started coding and finished implementation. I compiled and started the os with qemu.
But i got this error immidiately after i selected os:



I debugged with gdb and i got error when main function invokes gdt_install function:



My kernel.c and gdt.c files are as follows:

kernel.c


gdt.c


Do you have any solution? Thanks in advance.

[simeonz]

If I understand correctly, gdt_install's frame is executed in real mode, but it was compiled with gcc/clang for IA-32 (i.e. i386/i686) architecture, which means that both the code and the debug information are incorrect for the processor mode. For this reason, normally the pre-pm code is written in assembly, although technically gcc has a way to produce inefficient real mode code, I believe.

Additionally, errors like this happen in gdb from time to time, and can be due to disagreement between the compiler and gdb bugs. Also, incorrect architecture setting in gdb can cause this. It can be controlled with "set architecture", which is necessary for the pre-pm code, because it is actually running in different mode than the rest of the code (understandably).

[quiet]

Thank you for your response. But, all of the other files, libc functions, vga driver are written in C as well and compiled the way gdt.c was compiled. What's different about gdt.c?

[MichaelPetch]

Thank you for your response. But, all of the other files, libc functions, vga driver are written in C as well and compiled the way gdt.c was compiled. What's different about gdt.c?

Maybe you have set up an invalid GDT. We'd probably have to see your code to make a determination.

[simeonz]

Thank you for your response. But, all of the other files, libc functions, vga driver are written in C as well and compiled the way gdt.c was compiled. What's different about gdt.c?

In real mode, the return address on the stack is 16-bit wide (although you shouldn't return after switching PM), the base pointer is 16-bit wide, etc. Gdb will expect that the addresses on the stack and operands are 32-bit wide and indeed, being fragile as it is, may crash while trying to unwind the stack or perform other frame related operations (it is not very stable). Furthermore, although the 16-bit and 32-bit opcodes are somewhat compatible, the compiler may generate code which inappropriately computes stack pointer offsets, etc. To put in other words, you are deceiving the debugger and the compiler about the execution mode in which you are running. After you switch PM on, the architecture will be as expected, so all drivers and other code that runs after that point runs with the right conditions. You could coerce the debugger to recognize real mode by using "set architecture i8086", but you cannot mix architectures inside the same object file.

P.S. As I said, the boot code preceding the PM switch is usually written in assembler, and can be debugged using "set architecture i8086" if necessary.

[MichaelPetch]

In real mode, the return address on the stack is 16-bit wide (although you shouldn't return after switching PM), the base pointer is 16-bit wide, etc.

I believe meaty skeleton is a GRUB based project (for purposes of booting) and if they have written it the same way they are already in protected mode and not real mode.

[simeonz]

I believe meaty skeleton is a GRUB based project (for purposes of booting) and if they have written it the same way they are already in protected mode and not real mode.

I see. It is multiboot image indeed. I just saw that the switch_pm function is switching to protected mode. May be the OP modified it and it is not a multiboot image anymore. In either case, the mode can be checked by looking at the output of "monitor info registers" in gdb. It will show the cr0 register. "show architecture" in gdb may reveal a problem with gdb's comprehension of the current mode. It then can be fixed by using "set architecture" as I already mentioned. I don't know.

[quiet]

Thank you for your responses. I solved it. Problem was a syntax mistake in the assembly code. I am not used to GAS syntax but anyway it is solved.
simeonz, thank you for gdb tips they were useful.