OSDev.org

Im in the process of writing my memory management code and I need to determine the total kernel size at runtime so my memory manager can allocate the proper amount of memory. I am working off a recent post on alt.os.development: Determining kernel size at runtime

The problem is when I goto compile, LD bombs with: SIZEOF forward reference of section .text. I cant figure out why this happens. Maybe someone can help me out.

linker.ld I call it like this:

the fact .rodata* is inserted in .text section *after* you try to compute its size may be the source of the problem

if i were you, i would forget about text_size=SIZEOF(.text) in the .text section and have all those symbols in a dedicated .sizes section ...

i'm not sure it'll work, though ... i tend to have programs reformatting the object files after the linker did its job rather than doing complex things in linker scripts

why not just ditch text_size, data_size and bss_size entirely and just od this:
i think that'll be allowed (not 100% sure but i dont see why not)

proxy

afaik the assignment in the linker scripts assigns an address to a variable (even if it isn't declared in the sources) and allocates memory for it. Assigning a size to it is not practical. BTW, you can calculate it or get it from the ELF itself (assuming you use ELF again).

How about something simpler.

Ignore the linker script.

You have to load in X amount of sectors into memory for your kernel.
Multiply the amount of sectors loaded by the sector size.
Round up to a 4K boundary. (Assuming 4K page size)
Store the result in a variable - _kernel_size.

This approach takes into account different sector (or cluster depending on your loader) sizes of hard disks as well as the good old floppy.
The linker script can only tell you the size of the kernel in the increments the script uses. This could result in a miscalc of size when loading.
Page size may not be equal to sector (or cluster) size, at worst you'd waste whatever is left in the last sector (or cluster) of your kernel.

I start allocating kernel heap directly after the kernel.
k_heap_start = (_kernel_size + kernal load address).
k_heap_start = (_kernel_size + 0xC0000000)

hum ... and how do you initially know the value of X ?
btw, it sounds like BeyondSociety doesn't check his own post ::)

Pype.Clicker wrote: hum ... and how do you initially know the value of X ?
btw, it sounds like BeyondSociety doesn't check his own post ::)

or he fixed this some weeks ago and hasn't seen the new replies

Candy wrote:

Pype.Clicker wrote: hum ... and how do you initially know the value of X ?
btw, it sounds like BeyondSociety doesn't check his own post ::)

or he fixed this some weeks ago and hasn't seen the new replies

Ive been rather busy. At the moment Im still working on a solution to this. I'll have to add it to my todo list. I have quite a few things to fix in my os. Im still open to suggestions.

beyondsociety wrote: Im in the process of writing my memory management code and I need to determine the total kernel size at runtime so my memory manager can allocate the proper amount of memory. I am working off a recent post on alt.os.development: Determining kernel size at runtime

The problem is when I goto compile, LD bombs with: SIZEOF forward reference of section .text. I cant figure out why this happens. Maybe someone can help me out.

linker.ld

Code: Select all

OUTPUT_FORMAT("binary") 
OUTPUT_ARCH(i386)
ENTRY(_start)

SECTIONS
{        
       . = 0x100000;

       .text :
       {              
??????   kernel_code = .;  
??????   *(.text)
??????   text_size = SIZEOF(.text); ??????

??????   *(.rodata)
??????   . = ALIGN(4096);??????
       }

       .data :
       {     
??????   kernel_data = .;           
     ??????   *(.data)
??????   data_size = SIZEOF(.data); 
??????   . = ALIGN(4096);
??????
       }

       .bss : 
       {          
??????   kernel_bss = .;      
??????   *(.bss)
??????   bss_size = SIZEOF(.bss); 

??????   *(COMMON)
??????   . = ALIGN(4096);??????
        }
        kernel_end = .;
        kernel_size = text_size + data_size + bss_size;
}

I call it like this:

Code: Select all

extern _kernel_size, _kernel_end;
printk("Total kernel size: %i\n", kernel_end - kernel_size +1);

what's this code? any introductions /tutorials exist ?

I'm a semi-newbie but why can't you just put a "EOF:" label at the end of your code? Not using ASM? Or maybe multiple modules?

this is a 'linker script', telling how things coming from various compiled .o files should be arranged in one single binary file.

See http://es-sun2.fernuni-hagen.de/cgi-bin ... ld)Scripts

And no, having 'eof:' symbol at the end of an ASM file isn't helpfull since you'll have hard time saying the linker 'this is the file you should use last'.

Imho, BeyondSociety's problem could simply be solved by moving "text_size", "data_size" and "bss_size" out of their respective sections and placing them after "kernel_end" ...

when do we need write the link script? how if we use other compiler rather than gnu ld?

most of the things the linker script does can be done through the command line, however, if you want to merge multiple sections into a single one (.text & .rodata -> .text), have fine control over the physical/virtual placing of your file, over which section is expected first/last or want to insert symbols that can only be computed after linking is complete (like kernel_size), linker scripts are a must.

If your non-gnu linker do have something similar, you'll have to translate things so that they behave properly... if it doesn't, pray so that you never need it ... or switch to a script-equiped linker.

Imho, BeyondSociety's problem could simply be solved by moving "text_size", "data_size" and "bss_size" out of their respective sections and placing them after "kernel_end" ...

I put the text_size, data_size, bss_size into a seperate .sizes section, used the above method I was using, and I am getting 1KB for my kernel. But when I look at the actual binary, it shows a size of 8KB.

Why is their such a difference? How reliable is it to use the linker script to compute the size?

could it be possible that SIZEOF() doesn't take the ALIGN()ment into account ? the other possibility would be that headers/symbols/whatever are still hanging around (but that would surprise me, considering your "output_format("binary")" command.

Using an hex editor would be the best way to check ...

what about ?