Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I'm trying to have a function that initializes all of the stuff in my kernel (framebuffer TTY, keyboard LEDS, serial port). But for some reason, when GCC compiles it, it inserts a bunch of junk before the actual function code starts. This junk code then gets executed, and proceeds to triple fault. I verified this by putting `__asm__ ("cli\n" "hlt")` before anything else in the function. And sure enough, there's like 20 garbage bytes in front of the `cli hlt` in the disassembly. I have the x86_64-elf cross compiler, with red zone disabled, and `-mcmodel=kernel` for both libgcc and for my kernel. You can find the source code to the problematic file here: https://github.com/techflashYT/Techflas ... initions.c. And the hex bytes & disassembly of the junk below.
It doesn't look at all like any of the examples in the wikipedia page you linked. I can understand if it was doing stuff with the base or stack pointers, but it's doing something wildly different (after the first 2 lines of disasm), and it causes a triple fault (I can tell, because I tried hex editing the binary to replace all of those bytes with 90h [nop], and it halts correctly)
Techflash wrote:This junk code then gets executed, and proceeds to triple fault
It's not junk, it's part of the code for populating the kernTTY, serial, and keyboard structs. You've turned on optimizations that cause the compiler to rearrange code. It causes a triple fault because it uses SSE registers and you haven't correctly initialized the CPU for SSE support.
Techflash wrote:and `-mcmodel=kernel` for both libgcc and for my kernel
Your kernel is definitely not using "-mcmodel=kernel".
Your kernel shouldn't be using the SSE registers. It will make things very complicated in your scheduler if it does use them. For this reason, you should pass the following arguments to GCC / Clang:
That will suppress SSE usage, along with AVX, MMX, and 3DNow, which are in the same vein as SSE. Note that I probably missed some options here, but you get the idea.
That should fix the triple fault.
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg
I would have suggested that, but Clang didn't support it back when I tried it. But that probably doesn't matter as I assume the OP is using GCC.
Octocontrabass wrote:(But you can't build x86-64 libgcc with SSE disabled without patching it. One of these days I'm going to figure out how to do that...)
That's quite unfortunate. Sounds like libgcc can be quite finicky.
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg
Techflash wrote:This junk code then gets executed, and proceeds to triple fault
It's not junk, it's part of the code for populating the kernTTY, serial, and keyboard structs. You've turned on optimizations that cause the compiler to rearrange code. It causes a triple fault because it uses SSE registers and you haven't correctly initialized the CPU for SSE support.
Techflash wrote:and `-mcmodel=kernel` for both libgcc and for my kernel
Your kernel is definitely not using "-mcmodel=kernel".
Whoops. I guess it isn't. I reset everything a few days ago. Still getting around to fixing some thing.
nexos wrote:Your kernel shouldn't be using the SSE registers. It will make things very complicated in your scheduler if it does use them. For this reason, you should pass the following arguments to GCC / Clang:
That will suppress SSE usage, along with AVX, MMX, and 3DNow, which are in the same vein as SSE. Note that I probably missed some options here, but you get the idea.
That should fix the triple fault.
Ahhh. So those are the SSE registers. I knew that they were from one of the extensions. I was just concerned about why that code was there in the first place.