OSDev.org

I'm at a very beginning of writing OS. I'm in protected mode attempting to write the simple physical memory manager and later enable paging. I've noticed that when I define some global variables my printing stops to work. I can't wrap my head around it why.

This is my repo: mios. Everything is working ok if this variable is not defined. I used the "cli;hlt" to stop in the function, I set the breakpoint in gdb and send nmi from qemu monitor to continue. The issue is:
String 0xfedf is empty. If I manually modify 0xfedf via gdb to some string I do get the expected results.

I also tried to define big array after this variable (and instead of it) just to see what it does. Did even char bigbuf[10240] = "AAA .... A" and test it with it. Print was not working but gdb dump shows that I didn't have array full of 10240 "A" in memory, just partially. As if even that was overwritten by 0s.

In the linker script I created a signature section to verify that the whole binary is loaded to memory.

When I dumped the memory from gdb I was able to find the string there. It can't be coincidence that it's at 0x1fedf. But I don't understand why. mm.o module is 32b.

Does your GDB memory dump match your kernel binary? That will tell you whether the problem is linking your binary or something else.

Also, unrelated, -mregparm=3 does not break variadic functions. It breaks bad code that relies on undefined behavior. You should use stdarg.h here.

It does not. Compiled gboot image and what is on the disk are the same. I went back to my bootloader code to see what's happening. I wrote a small python-gdb command to display DAP to spot easier what's happening. I found the problem. This part of the booloader is loading the partition. I set breakpoints after read and adjustment to see how that DAP packet looks like; shortly I saw this (before and after adjustment):
In my simple, inexperienced mind I thought jno instruction sets the OF when there's a wraparound. It didn't consider that OF is set either way - from neg to pos and vice versa.

This bug was triggering when I used regparm=3. There is no excuse to let it be as I did. Changing it to cdecl "fixed" it for a small period of time.

I was not sure what headers are "safe" to use and what should be rather written from ground up. So far I used only stdint. I'll rewrite it to use stdarg.
Many thanks for pointing out the issues.

mtbro wrote:I was not sure what headers are "safe" to use and what should be rather written from ground up.

The GCC documentation has a list of them:

a conforming freestanding implementation is only required to provide certain library facilities: those in <float.h>, <limits.h>, <stdarg.h>, and <stddef.h>; since AMD1, also those in <iso646.h>; since C99, also those in <stdbool.h> and <stdint.h>; and since C11, also those in <stdalign.h> and <stdnoreturn.h>.

Perfect, thanks.