Problem with drawing pixels in os development

I'm a bit new to the os development world and have been recently trying my hand at a 32 bit kernel, I'm using GRUB as the bootloader and I have already collected the vbe information (of course by setting the corresponding flag in the multiboot header). I've trying to write a function that draws pixels in my toy kernel:

void putpixel(int x, int y, int colour){    uint32_t loc = x * (graphmod->bpp / 8) + y * graphmod->pitch;    uint8_t *screen = (uint8_t *)graphmod->framebuf;    screen[loc] = colour & 255;    screen[loc + 1] = (colour >> 8) & 255;    screen[loc + 2] = (colour >> 16) & 255;    screen[loc + 3] = (colour >> 24) & 255;}

Now the issue is that this function won't draw pixels to the screen when I call it from my kernel if I put a function prototype for the function, though I highly suspect that it's because I use these options: -ffreestanding, -nostartfiles, -nostdlib to compile my code and I've noticed that some slight change in code that has no concern with the function can result in it not working. Though I've stated my suspicions it could as well be the function itself. Any help would be highly appreciated.

Note: I know I should have developed my own cross compiler but unfortunately network speeds are so slow and internet subscriptions are terribly expensive in my resident country. I tried downloading the gcc source code but after many corrupt downloads of the file I decided to do some research and I got those options which worked until now. And also note that the screen just shows that it's blank but nothing goes wrong.

EDIT: to provide more clarity here's the command to compile the kernel:

gcc kernel/kernentry.s kernel/isr.c kernel/descriptor_handlers/gdt.c kernel/descriptor_handlers/interrupts.c kernel/kernel.c drivers/pit.c drivers/pic.c utility/sys.s drivers/graphd.c -nostdlib -nostartfiles -ffreestanding -m32 -o debug/kernel.sys -Wl,-Tdebug/link.ld

I put it in a bash script file like so:

if gcc kernel/kernentry.s kernel/isr.c kernel/descriptor_handlers/gdt.c kernel/descriptor_handlers/interrupts.c kernel/kernel.c drivers/pit.c drivers/pic.c utility/sys.s drivers/graphd.c -nostdlib -nostartfiles -ffreestanding -m32 -o debug/kernel.sys -Wl,-Tdebug/link.ldthen    if grub-file --is-x86-multiboot debug/kernel.sys;    then        cp debug/grub.cfg isodir/boot/grub        cp debug/kernel.sys isodir/boot        grub-mkrescue -o gamos.iso isodir    fifi

I link it with this linker script(I forgot to add this in my list of suspects):

ENTRY(_load)SECTIONS{    . = 1M;    .text BLOCK(4K) : ALIGN(4K)    {        *(.multiboot)        *(.text)    }    .rodata BLOCK(4K) : ALIGN(4k)    {        *(.rodata)    }    .data BLOCK(4k) : ALIGN(4K)    {        *(.data)    }    .bss BLOCK(4k) : ALIGN(4K)    {        *(COMMON)        *(.bss)    }}

I used it in this function too and called it in my kernel after calling the putpixel function:

void rasterlet(){    char a[] = {0b00011000,                0b01111110,                0b01100110,                0b01111110,                0b01100110,                0b01100110};    int x = 3;    int y = 8;    for(int i = 0; i < 6; i++)    {        for(int j = 0; j < 8; j++)        {            if(a[i] & (1 << j))                putpixel(x, y, 0xffffffff);            x++;        }    }    }

EDIT: after many edits to my code (I also found a bug in the rasterlet function, I found out that the problem was from bochs because I loaded the same iso on qemu and it worked and quite surprisingly when I loaded it on bochs again it worked. I suspect it's a lag or some kind of bug. Well that's it.