[Solved] Unable to access data; probably linking issue

[mtbro]

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:

Code: Select all

   0x0000f3ae:	push   0x81d8
   0x0000f3b3:	push   0xfedf      <-- str to print
   0x0000f3b8:	call   0xdb95
   0x0000f3bd:	cli
   0x0000f3be:	hlt
=> 0x0000f3bf:	mov    ebx,0x81d8
   0x0000f3c4:	add    esp,0x10

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.

[Octocontrabass]

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.

[mtbro]

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):

Code: Select all

DAP: 7b54
size:	0x10
blocks:	1
buf:	07c0:7e00 ( 0xfa00 )
LBA:	0x83f

DAP: 7b54
size:	0x10
blocks:	1
buf:	17c0:8000 ( 0x1fc00 )
LBA:	0x840

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.

[Octocontrabass]

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

[mtbro]

Perfect, thanks.