determining the kernel size

[Bughunter]

It's 15454 bytes. Which equals 0x3C5E. Well, that is the raw size. The virtual size might be bigger.

How can I get the true virtual size and how can I get the raw size (i.e. dynamically)?

[os64dev]

So by modifying the example, would this be a correct way to determine the kernel size?

Code: Select all

ENTRY (_loader)

SECTIONS{
    kernel_start = .;

    . = 0x00100000;

    .text :{
        *(.text)
    }

    .rodata ALIGN (0x1000) : {
        *(.rodata)
    }

    .data ALIGN (0x1000) : {
        *(.data)
    }

    .bss : {
        _sbss = .;
        *(COMMON)
        *(.bss)
        _ebss = .;
    }

    kernel_size = . - kernel_start;
}

Well the above is not correct kernel_start should be after the . = <address> line also it does not give you the filesize of the kernel. Only the text and data segments are needed in the file so before the .bss you can add a line kernel_file_size = . - kernel_start; Further more the values are not aligned which might give performance issues if you use those value for memory managment and don't allign in the mmu code. The concept is ok however.

[os64dev]

My kernel now reports its size is 0x9000 bytes, while when I manually sum up the sizes of all sections (by doing 'objdump -h') I get a size of 0x7487.

Where do the other 0x1B79 bytes come from? Padding? Maybe I don't know ELF good enough. Can anyone shed some light on this?

i think elf aligns segments on a 0x1000 (4 KiB) boundry

[Bughunter]

Well the above is not correct kernel_start should be after the . = <address> line also it does not give you the filesize of the kernel.

That part actually was already fixed, I just didn't update it here. Thanks for noticing the bug though

I now just use the size I get by using the linker symbols as the virtual size. Finding the size of the file on disk by just doing linker symbol calculations is not possible (maybe in a very comprehensive way but it doesn't matter because I wanted the virtual size).