Too big kernel binary size

[giszo]

Hi!

It's a long time since last time I touched my OS sources. Now I did a fresh recompile on it and tried to continue the work, but when I tried to load it with GRUB, it just says that the kernel binary has an invalid or unsupported format. I just started to check my kernel binary and noticed that its size is about 1.3Mb. This looks a bit strange for me as the kernel binary should be at around 200kB or so.

Here's my linker script:

Code: Select all

OUTPUT_FORMAT("elf32-i386")
OUTPUT_ARCH(i386)

ENTRY(_start)

SECTIONS {
    . = 0x100000 + SIZEOF_HEADERS;

    .text : {
        *(.multiboot_header)

        *(.text)
        *(.text.*)
        *(.gnu.linkonce.t*)

        __smp_trampoline_start = .;
        *(.smp_trampoline)
        __smp_trampoline_end = .;
    }

    . = ALIGN(0x1000);

    .rodata : {
        *(.rodata)
        *(.rodata.*)
        *(.gnu.linkonce.r*)
    }

    . = ALIGN(0x1000);
    __ro_end = .;
    __data_start = .;

    .data : {
        *(.data)
        *(.data.*)
        *(.gnu.linkonce.d*)
    }

    . = ALIGN(0x1000);

    .bss : {
        *(.bss)
        *(.bss.*)
        *(.gnu.linkonce.b*)
    }

    . = ALIGN(0x1000);
    __k_init_start = .;

    .kinit : {
        *(.kernel_init)
    }

    . = ALIGN(0x1000);
    __kernel_end = .;
}

What could cause this strange binary size?

[Creature]

It seems as if you're using C++ (because of the linkonce sections, which usually show up with templates and other C++ stuff). I've had this bug countless times too, it's because I didn't accomodate for some linkonce sections in the right place, so GCC just dumps them somewhere inappropriate, messing the entire executable up.

You should make sure the multiboot header is placed first (which I'm guestimating is *(.multiboot_header), so this seems to be correct).

You seem to have all the linkonce sections, the only difference that I have in my C++ kernel is that I put all the linkonce sections in a separate section:

Code: Select all

.extra :
	{
		/* Extra sections created by GCC that need to be handled (otherwise binary size might largely increase). */
		*(.gnu.linkonce.t*)
		*(.gnu.linkonce.r*)
		. = ALIGN(4096);
	}

Which I put underneath .bss. I never thought that they needed to be put in their appropriate sections (I didn't even know the ".r" stood for .rodata or something, I only knew they had to be handled so I dropped 'em all here).

So if the suffixes indeed stand for the section they should be placed, I don't see anything immediately wrong with your code. I've never suffered from this problem again after I put them all together in one section, but never tried putting them separately (but then again, this problem usually tends to pop up again after moving or adding some things).

Maybe someone else could give a more detailed explanation, though.

[giszo]

It seems as if you're using C++ (because of the linkonce sections, which usually show up with templates and other C++ stuff). I've had this bug countless times too, it's because I didn't accomodate for some linkonce sections in the right place, so GCC just dumps them somewhere inappropriate, messing the entire executable up.

Actually I'm using C only and compiling with GCC, so my kernel has nothing to do with C++. I just added those linkonce sections recently while I was reading the topic you mentioned. Unfortunately adding these stuffs didn't help

[giszo]

One more news: I switched back from binutils-2.20 to binutils-2.19.1 and now the problem is solved. Still I don't know what causes the problem

[NickJohnson]

You could try a "readelf -S" to find which segment is taking a huge amount of space, or at least if the problem is in the loadable data itself.

[Creature]

One more news: I switched back from binutils-2.20 to binutils-2.19.1 and now the problem is solved. Still I don't know what causes the problem

Yes, I remember that too, I switched to binutils 2.20 recently as well and also noticed that the problem returned. Apparently this was because I only had a section for "*(.rodata)" and not for any other symbols suffixed by rodata, so what I forgot was "*(.rodata*)". I also forgot the asterisk for the other sections and it worked fine again afterwards.

[petroms]

Hi!

I'm reviving yaosp!
(http://forum.osdev.org/viewtopic.php?f=2&t=21793)

On an old 32 bit host with debian on it I could compile it and got a working binary, but now when I compile it on a modern x86_64 with up to date toolchain I run into the same problem.
My binary ends up huge with big segments of zero bytes.
Does anybody have any idea why that happens?

https://github.com/attilaszia/yaosp/

A git clone and ./start.sh should start the build.