Some functions of the Kernel (Screen Driver) don't compile properly - osdev

Question

I am building an OS kernel. I face a problem when some of the functions aren't compiled properly.

I compile the code using a gcc compiler on a Linux subsystem on Windows. But when I compile the code, it isn't getting beyond 13833 bytes. This creates problem as the screen driver functions (the print functions) which are present at the last don't work properly.

Even when I added a thousand uint64_t variables through an array, even then the size doesn't increase. This problem is possibly in the build process.

My makefile is-

DIRECTORIES = boot kernel drivers HALx86 dataman physmm

C_SOURCES = $(wildcard HALx86/*.c dataman/*.c physmm/*.c drivers/*.c)
ASM_SOURCES = $(wildcard HALx86/*.asm)

CC = gcc
CFLAGS = -DDEBUG -m32 -ffreestanding -c -nostdlib -lgcc

KERNEL = kernel/kernel_start.o kernel/kernel.o

ASM = nasm
AOFLAGS = -f elf32 -o
ABINFLAGS = -f bin -o

OBJ = ${C_SOURCES:.c=.o}
ASMOBJ = ${ASM_SOURCES:.asm=.o}

all: os-image.img

os-image.img: boot/boot_sector.bin boot/boot_stage2.bin kernel/kernel.bin
    cat $^ > $@
    echo "OS Image size:"
    wc -c os-image.img

kernel/kernel.bin: ${KERNEL} ${ASMOBJ} ${OBJ}
    ld -melf_i386 -o $@ -Ttext 0x1000 $^ --oformat binary

%.o : %.c
    $(CC) $(CFLAGS) $< -o $@

%.o : %.asm
    $(ASM) $< $(AOFLAGS) $@

%.bin : %.asm 
    nasm $< $(ABINFLAGS) $@

clean:
    rm -fr kernel/*.o
    rm -fr drivers/*.o
    rm -fr HALx86/*.o
    rm -fr dataman/*.o
    rm -fr physmm/*.o
    rm -fr boot/*.bin
    rm -fr os-image.img *.bin *.o

rebuild:
    make clean
    make

backup:
    make clean
    zip -r backups/BACKUP_DATE-`date +%d-%m-%Y_%H-%M-%S`.zip $(DIRECTORIES) README.txt makefile
    make

I'm only addressing the last comment about adding variables. Adding uninitialized global variables (or a global variable set to 0) to your program won't increase its size because they are placed in the _BSS_ segment. The _BSS_ area by default (unless you write your own linker script) isn't placed inside the binary. — Michael Petch, May 21 '17 at 14:27
Your question is vague. What isn't getting passed 13833 bytes?? What error ar you getting or how does it fail? Is this a compile error or some error that happens when you run your kernel? — Michael Petch, May 21 '17 at 14:33
It is a runtime error. It doesn't cause any fatal error. When I add more functions the kernel size should increase. But it doesn't. Rather the already existing functions fail to work probably because they aren't compiled. I understood that the variables don't increase the size. But the functions should. @MichaelPetch — Anish Sharma, May 21 '17 at 14:44
Is your bootloader reading enough sectors into memory to load the entire kernel? — Michael Petch, May 21 '17 at 15:54
If you put all of your code into a GitHub project (or somother online revision control) I could take a look. There isn't enough information here to provide an answer. — Michael Petch, May 21 '17 at 16:11
I would do that tomorrow morning as soon as I could. Sorry I couldn't do it now and Thanks :) @MichaelPetch — Anish Sharma, May 21 '17 at 16:13
I wasn't able to create a GitHub repository with my IDE. I am sharing a link on google drive - https://drive.google.com/file/d/0B5a3grynZR51WWw0d3VBTXBocjA/view?usp=sharing Here is my code @MichaelPetch — Anish Sharma, May 22 '17 at 16:17
I assume that the error you are referring to is that your stage 2 prints `Error1` ? — Michael Petch, May 22 '17 at 17:41
No. The kernel launches without showing any error but the functions don't work properly. @MichaelPetch — Anish Sharma, May 23 '17 at 00:48
I actually get an error if I run the image that you put in your zip file via QEMU. Sorry I know why I got it. I booted off as a hard disk, not a floppy. Ignore my comment then — Michael Petch, May 23 '17 at 00:50
I get some stuff on the screen. How do I know it isn't working? I'm hoping what you put in the ZIP file is something that doesn't work. — Michael Petch, May 23 '17 at 00:51
The print statements in the `kernel.c` are more than what is printed. @MichaelPetch — Anish Sharma, May 23 '17 at 00:54
Okay, I see the lines in the `kernel.c` that you are printing and don't appear to show up. When I get a chance in a few hours I'll take a look closer as to the cause. — Michael Petch, May 23 '17 at 00:56
The problem isn't in how you build your image. The problem is in `boot_stage2.asm`. You are incorrectly reading the sectors from the disk so not all the data is loaded in memory. When you reach 18 sectors you increase the cylinder count. You should increment the head count and set the sector number back to 1. If the head count reaches 2 (2 heads on a floppy) you should set head back to 0 and increment the cylinder number. As it is you are only correctly read sectors 4 through 18. Once you hit sector 19 you are reading from the wrong location and data (strings etc) are not loaded into memory. — Michael Petch, May 23 '17 at 02:47
Actually come to think of it you aren't even reading sector 18 correctly. Sectors start from 1. You check when the sector reads 18 but don't actually read sector 18. But I think that should be comparing to 19 as you want to read 1 to 18 (including 18) — Michael Petch, May 23 '17 at 03:03
I had misunderstood that the next track comes after the first. Now I have changed the code and it works!! Thanks @MichaelPetch — Anish Sharma, May 23 '17 at 03:22

Some functions of the Kernel (Screen Driver) don't compile properly - osdev

0 Answers0