Multiboot Kernel

[Candy]

Don't bother. Extra 4k for the kernel size hardly matters, especially as it's only the disk-size, not the final loaded size (assuming Candy is correct). Plus if you really care about disk-size, then you can gzip the resulting binary (Grub loads those as well) at which point the difference probably reduces to insignificance.

I expect a 4-5 byte difference in final size if you compress it.

[Bughunter]

Hmm but I would like to know what exactly happens and how to fix it

Btw later on I am going to code my own boot loader again like I did with my ASM kernel, so I'll have to implement GZIP or some other compression method there too if I am choosing for compressing it.

[Candy]

Hmm but I would like to know what exactly happens and how to fix it

Well....

The difference is caused because the default linker script is different between objdump reassembling an object from a PE dump made and a native ELF object creation. It's either objcopy not using a linker script (which I would expect) or ld not using / following it properly in some case (which I can also expect but would hope not to be). I've messed with LD in 64-bit code a while ago when it wouldn't stop aligning stuff at 1MB boundaries.

If you want to see the differences for comparison, try using gzip to quantify whether there's contentual difference (if the files are contentually different, they'll compress to wildly varying sizes). You can also use hexdump (-C) for checking the binary content (as I occasionally do) or objdump -d for disassembling the object itself.

Btw later on I am going to code my own boot loader again like I did with my ASM kernel, so I'll have to implement GZIP or some other compression method there too if I am choosing for compressing it.

Yep. I've made a compressor that's public domain, decompressor is available in two forms, one 60-byte one for in a boot sector (guess where I use it? ), one C version that fits in a setup block. There's a compressor that compresses in unix but it's very inefficient (O(n^4) about (so if you double the size of the file it'll take 16 times as long).

[Bughunter]

The difference is caused because the default linker script is different between objdump reassembling an object from a PE dump made and a native ELF object creation. It's either objcopy not using a linker script (which I would expect) or ld not using / following it properly in some case (which I can also expect but would hope not to be). I've messed with LD in 64-bit code a while ago when it wouldn't stop aligning stuff at 1MB boundaries.

.....

Yep. I've made a compressor that's public domain, decompressor is available in two forms, one 60-byte one for in a boot sector (guess where I use it? ), one C version that fits in a setup block. There's a compressor that compresses in unix but it's very inefficient (O(n^4) about (so if you double the size of the file it'll take 16 times as long).

But I've setup an ELF cross compiler for use with Cygwin so it should have nothing to do with PE?

When using GZIP on my kernel it goes from (after using strip) 8648 bytes to 515 bytes.

Btw can you post a link to your compressor/decompressor and to the documentation of it as well (or an example of the implementation maybe)?

[Candy]

But I've setup an ELF cross compiler for use with Cygwin so it should have nothing to do with PE?

When using GZIP on my kernel it goes from (after using strip) 8648 bytes to 515 bytes.

Btw can you post a link to your compressor/decompressor and to the documentation of it as well (or an example of the implementation maybe)?

Then I can only see the linker script (default linker script?) as reason.

The compressor (it's slow, don't interrupt it, it's been known to take a few minutes on larger files):
http://atlantisos.svn.sourceforge.net/v ... ompressor/

[Bughunter]

This is my current linker script:

Code: Select all

ENTRY(start)
OUTPUT_ARCH(i386)
OUTPUT_FORMAT(elf32-i386)

SECTIONS
{
    . = 0x00100000;

    .multiboot.header :
    {
        *(.multiboot.header)
    }

    .text :
    {
        *(.text)
    }

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

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

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

[Bughunter]

Shameless bump

Candy (or somebody else), can you verify that the linker script is correct? What else can I try?

[mystran]

If you are using the same script on both systems, I guess you use -T <script> as parameter for linker (to explicitly replace the default script)? And give the linker all the parameters in the same order?

[mystran]

Oh and you can just put the special boot section within .text as it's not useful to have it as a separate section after the linker has run..

edit: and you don't need to align the sections in the linker script since your object files will contain relevant alignment requirements anyway

[Bughunter]

If you are using the same script on both systems, I guess you use -T <script> as parameter for linker (to explicitly replace the default script)? And give the linker all the parameters in the same order?

Well actually I use --script instead of -T, but I've tried -T also on both systems which didn't make any difference. The reason that I use '--script' is because it's unlikely to change in future versions.

Oh and you can just put the special boot section within .text as it's not useful to have it as a separate section after the linker has run..

edit: and you don't need to align the sections in the linker script since your object files will contain relevant alignment requirements anyway

That's true I guess, I've removed the alignments from the linker script. Also I have placed *(.multiboot.header) inside *(.text). Thanks for the tip It's actually one of my first experiences with linker scripts, but logically thinking of how it such a script works, helps understanding it.

But on my Slackware it now works! I guess because of the multiboot header subsection (if I can call it that?) now resides inside the TEXT section.

After doing a GZIP -9 on the final thingie, it was only 455 bytes (without GZIP it's about 5kB), pretty good compression.

[R2_]

I had same prob under ubuntu then I switched to fedora and it worked

[Bughunter]

I had same prob under ubuntu then I switched to fedora and it worked

If you read my last post I've now fixed it under Slackware.

[mystran]

Well actually I use --script instead of -T, but I've tried -T also on both systems which didn't make any difference. The reason that I use '--script' is because it's unlikely to change in future versions.

Yeah well, -T and --script are the same thing.

[Bughunter]

Yeah well, -T and --script are the same thing.

Yep Btw thanks to you for your help