OSDev.org

Posted: **Tue Aug 17, 2021 6:27 am**

Hey guys, i am writing a small scale OS from scratch, somewhat inspired from Here

I have the following c code and nasm code

Code: Select all

void main()
{
 char* VID = (char*)0xb8000;
 *VID = 'X';
}

and

Code: Select all

[bits 32]
[extern main]
    call main
    jmp $

I compile these with the following commands

Code: Select all

nasm -f elf32 -o kernel_entry.o kernel_entry.asm
gcc -ffreestanding -fno-pie -m32 -c kernel.c -o kernel.o

and i link these together with the following command

Code: Select all

ld kernel_entry.o kernel.o -o kernel.bin -m elf_i386 -Ttext 0x1000 --oformat binary

which i later cat with my bootsector binary to obtain a qemu operatable binary
The sizes of the individual object files is very less < 1 kb
But after linking, the binaries explode to 135+MBs
The huge binary works, but it still feels weird

I did an ndisasm of the kernel.bin file and i found a lot of space filled with

Code: Select all

0000009E  6A0C              push byte +0xc
000000A0  FF75FC            push dword [ebp-0x4]
000000A3  FF75F4            push dword [ebp-0xc]
000000A6  E894FFFFFF        call 0x3f
000000AB  83C40C            add esp,byte +0xc
000000AE  90                nop
000000AF  C9                leave
000000B0  C3                ret
000000B1  0000              add [eax],al
000000B3  0000              add [eax],al
000000B5  0000              add [eax],al
000000B7  0000              add [eax],al
000000B9  0000              add [eax],al
000000BB  0000              add [eax],al
000000BD  0000              add [eax],al
000000BF  0000              add [eax],al
000000C1  0000              add [eax],al
000000C3  0000              add [eax],al
000000C5  0000              add [eax],al

and such padding type instructions filled the whole way.
I would like to know whats going on here and any ways to fix it.
Found a similar problem on stack overflow and heres the link here

Posted: **Thu Aug 19, 2021 6:16 pm**

One of the sections in your binary has a very high address. When you tell the linker to turn it into a flat binary, the linker has to insert padding so it ends up at the expected address. You can use objdump or readelf to see exactly what it is.

You should be using a cross-compiler.

Posted: **Thu Aug 19, 2021 10:13 pm**

I fixed the exploding binary issue, kinda by using a cross compiler and linking with that, its a 32bit cross compiler and it does its job well of linking and the obtained binary is also of reasonable size.

Another issue which has come up is the qemu os image works only in fda mode and not in hda mode, which the earlier huge binary file could work in.
The value left in the ah register after error in disk read is printed onto the screen

: Screenshot from 2021-08-20 09-42-12.png (7.41 KiB) Viewed 3390 times

Posted: **Fri Aug 20, 2021 6:14 am**

Was DL clobbered before reading the sector? Hard disk 0 typically has a drive number of 80h. Also, I would recommend using LBA BIOS functions, as they are a lot easier to work with in the long run then those CHS functions.

Posted: **Fri Aug 20, 2021 8:49 am**

Are you sure "0x7<<:" is the right error code?

Posted: **Fri Aug 20, 2021 6:14 pm**

I managed to fix the issue of it running only in fda mode. The issue was that the os binary generated was too small for the sectors to read apparently, resizing the os image to a minimum of 20k fixed it, heres the solution i found on stack overflow HERE

OSDev.org

Binary linked from object files explodes in size

Binary linked from object files explodes in size

Re: Binary linked from object files explodes in size

Re: Binary linked from object files explodes in size

Re: Binary linked from object files explodes in size

Re: Binary linked from object files explodes in size

Re: Binary linked from object files explodes in size