Re: Problem loading kernel
Posted: Sun Jan 06, 2013 10:20 pm
Hi,
Normally you'd probably have 3 sections in the file (.text, .rodata, .data), not including ".bss" which isn't in the file. Normally you'd make each of these sections start on a 4 KiB boundary, so that the page's attributes can be set correctly (e.g. so you get a page fault if you try to write to ".text" or ".rodata").
For PE files, I'd expect the file itself would not include most of this padding - e.g. sections might be aligned on 512 byte (sector) boundaries in the file, and only aligned on 4 KiB boundaries when it's loaded into memory (where it still consumes RAM). If you convert it to flat binary, then the padding between sections would need to be included so that sections still start at the right virtual addresses.
For example; the original PE file might have 1 byte of ".text" then 511 bytes of zeros in the file, then another 3.5 KiB of "implied padding" that isn't in the file at all; then 1 byte of ".rodata", 511 bytes of zeros and another 3.5 KiB of "implied padding"; then 1 byte of ".data". In this case the total file (excluding PE headers, etc) might be 1.5 KiB. When this example gets converted to flat binary, you'd end up with a 1 byte then 4095 zeros then 1 more byte then 4095 zeros then the last byte; or (slightly more than) 8 KiB.
If this is the case, then the solution to the problem is to either write more code (e.g. for a 5 MiB kernel a few KiB of padding would be barely noticeable) or to tell the linker not to bother with the 4 KiB alignment.
Cheers,
Brendan
The first step to fixing any problem is to understand why that problem exists.BMW wrote:Lol, chucked a 2.5KB PE file into objcopy, spat out a 9KB binary file 99% full of 0x00... im not putting up with that.
How can I fix this?
Normally you'd probably have 3 sections in the file (.text, .rodata, .data), not including ".bss" which isn't in the file. Normally you'd make each of these sections start on a 4 KiB boundary, so that the page's attributes can be set correctly (e.g. so you get a page fault if you try to write to ".text" or ".rodata").
For PE files, I'd expect the file itself would not include most of this padding - e.g. sections might be aligned on 512 byte (sector) boundaries in the file, and only aligned on 4 KiB boundaries when it's loaded into memory (where it still consumes RAM). If you convert it to flat binary, then the padding between sections would need to be included so that sections still start at the right virtual addresses.
For example; the original PE file might have 1 byte of ".text" then 511 bytes of zeros in the file, then another 3.5 KiB of "implied padding" that isn't in the file at all; then 1 byte of ".rodata", 511 bytes of zeros and another 3.5 KiB of "implied padding"; then 1 byte of ".data". In this case the total file (excluding PE headers, etc) might be 1.5 KiB. When this example gets converted to flat binary, you'd end up with a 1 byte then 4095 zeros then 1 more byte then 4095 zeros then the last byte; or (slightly more than) 8 KiB.
If this is the case, then the solution to the problem is to either write more code (e.g. for a 5 MiB kernel a few KiB of padding would be barely noticeable) or to tell the linker not to bother with the 4 KiB alignment.
Cheers,
Brendan