I expect a 4-5 byte difference in final size if you compress it.mystran wrote: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.
Well....bughunter wrote:Hmm but I would like to know what exactly happens and how to fix 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?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.
), 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?Candy wrote: 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?
Then I can only see the linker script (default linker script?) as reason.bughunter wrote: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)?
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 = .;
}
}
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.mystran wrote: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?
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 tipmystran wrote: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
It's actually one of my first experiences with linker scripts, but logically thinking of how it such a script works, helps understanding it.
If you read my last post I've now fixed it under Slackware.R2_ wrote:I had same prob under ubuntu then I switched to fedora and it worked
Yeah well, -T and --script are the same thing.bughunter wrote: 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.
Yepmystran wrote: Yeah well, -T and --script are the same thing.
Btw thanks to you for your help