Writing C functions for bare metal development on intel x86, linker reports overflow

1

I am trying to build an OS from scratch. Beginning from the first instruction in 0xFFFFFFF0 and so on. To do so, I am using assembly code (NASM) and C code (gcc). But I'm doing something wrong. I've writen a C function to copy the kernel code from the NVRAM to the RAM, but I have the next error in the ld linker.

 ld -z max-page-size=0x1000 --oformat=binary -m elf_i386 -T ./linker.ld -e reset ./obj/init16.o ./obj/A20Gate.o ./obj/init32.o ./obj/kernel.o ./obj/reset.o ./obj/systable.o ./obj/functions_rom.o -o ./bin/mibios.bin 
ld: ./bin/mibios.bin section `.note.gnu.property' will not fit in region `rom'
ld: region `rom' overflowed by 18446744073709527104 bytes
make: *** [Makefile:13: bin/mibios.bin] Error 1

I belive that I am compiling the C code in a wrong way and I can not find the correct way to do it.

The relevant parts of the code are the following:

Linker Script:

ENTRY(reset) /*declaro el punto de entrada al programa*/


    /*VMA*/
    __RESET_VMA = 0xFFFFFFF0;
    __KERNEL_VMA = 0x00200000;
    __INIT16_VMA = 0xFFFF0000;
    __INIT32_VMA = 0xFFFF8000;
    __FUNCTIONS_ROM_VMA = 0xffffA000;


    __SYS_TABLES_VMA = 0xFFFFFD00; /*Es la seccion donde se guardan las tablas del sistemas*/

    /*LMA*/
    __RESET_LMA = 0xFFFFFFF0;
    __KERNEL_LMA = 0xFFFF2000;
    __INIT16_LMA = 0xFFFF0000;
    __INIT32_LMA = 0xFFFF8000;
    __SYS_TABLES_LMA = 0xFFFFFD00;
    __FUNCTIONS_ROM_LMA = 0xffffA000;
    
    __STACK_START_32    = 0x1FF08000;
    __STACK_END_32      = 0x1FF08FFF;
    __STACK_SIZE_32     = ((__STACK_END_32 - __STACK_START_32) / 4);   /*32b word*/

    __FUNCTIONS_LMA             = 0xffff1000;   
    __FUNCTIONS_VMA             = 0x00000000;
MEMORY
{
    ram (!x) : ORIGIN = 0x00000000, LENGTH = 0xffff000  /*2**32(4G)-2**16(64k)*/
    rom (rx) : ORIGIN = 0xffff0000, LENGTH = 0x00010000
}

SECTIONS
{
    .codigo_kernel __KERNEL_VMA :
    AT ( __KERNEL_LMA )
    { *(.kernel); } > ram
    __kernel_size = SIZEOF(.codigo_kernel);


    .codigo_init16 __INIT16_VMA :
    AT ( __INIT16_LMA )
    {
        *(.Init16);
        *(.a20Gate);
    } > rom


    .codigo_init32 __INIT32_VMA :
    AT (__INIT32_LMA)
    {*(.Init32);} > rom

    .sys_tables __SYS_TABLES_VMA :
    AT (__SYS_TABLES_LMA)
    {*(.sys_tables);} > rom

    .reset __RESET_VMA :
    AT (__RESET_LMA)
    {*(.reset);} > rom

    .functions_rom __FUNCTIONS_ROM_VMA :
        AT( __FUNCTIONS_ROM_LMA )
        { *(.functions_rom*); } > rom

    .functions __FUNCTIONS_VMA :
        AT ( __FUNCTIONS_LMA )
        { *(.functions); } > ram
    __functions_size = SIZEOF(.functions);

}

C function:

#define byte char
#define dword int

__attribute__(( section(".functions_rom"))) byte __fast_memcpy_rom(const dword *src, dword *dst, dword length)
{
    byte status= -1;
    if (length > 0)
    {
        while(length)
        {
            length--;
            *dst++ = *src++;
        }
        status = 1;
    }
    return(status);
}

compiling of the C function and linking:

LINKER_OBJECTS      = ./obj/init16.o ./obj/A20Gate.o ./obj/init32.o ./obj/kernel.o ./obj/reset.o ./obj/systable.o ./obj/functions_rom.o

LINKER_SRIPT        = ./linker.ld
LINKER_DEPENDENCIES = init16 A20Gate init32 kernel reset systable functions_rom
LINKER_ENTRY_POINT  = reset
OUTPUT              = ./bin/mibios.bin
AFLAG               = -f elf32
CFLAG               = -c -m32 -fno-stack-protector -fno-asynchronous-unwind-tables -Wall -fno-PIC

$(OUTPUT): $(LINKER_DEPENDENCIES)
    @echo Generando $@...
    ld -z max-page-size=0x1000 --oformat=binary -m elf_i386 -T $(LINKER_SRIPT) -e $(LINKER_ENTRY_POINT) $(LINKER_OBJECTS) -o $(OUTPUT) 


functions_rom: ./src/functions_rom.c
    @echo Generando $@.o...             
    mkdir -p bin
    mkdir -p sup
    gcc $(CFLAG) ./src/$@.c -o ./obj/$@.o -l ./sup/$@.lst

I know that this function is so simple that I could write in assembly. But I would like to know what the problem is and how to fix it before moving to more complicated functions.

c
assembly
gcc
osdev
asked on Stack Overflow Feb 21, 2021 by Gaston • edited Feb 21, 2021 by peterh

0 Answers

Nobody has answered this question yet.


User contributions licensed under CC BY-SA 3.0