binary format

[firas981]

If i decide to put the kernel in binary foramat ( instead of
elf or pe , ....) , what things I'll lose ?
thanks

[Ozguxxx]

Im currently doing in pure binary format and I do not think you would lose anything up to some point however elf, pe ... have nice features like dynamic linking so you wont lose anything but if you dont make use of them you (and I) will suffer from not having them...

[Candy]

dynamic linking, static linking after starting your kernel (not a normal idea, but what I'm doing), marking part of your executable as temporary, protecting the code from being modified, actually being able to tell what went where, getting a disassemble with symbol names & relocations, stuff like that

[Pype.Clicker]

there's nothing wrong 'per se' with flat binaries, but you'll have to make sure that it is loaded at the proper address (which the loader must be told in some way) and that it will have its entry point at a known offset.

Personnally, i prefer pre-pend the flat binary with a small header containing:
- a magic word ('KERN'), just to make sure i'm not loading junk
- the amount of bytes to be allocated for the kernel (just to make sure there's enough room to do so)
- the amount of bytes to be loaded from the disk (as i don't have FAT or whatever)
- the offset of the entry point.

alloc_size >= load_size, and 'extra' allocated space is wiped with zeroes (used for the .bss section)

[Tim]

But then if you're going to invent a bunch of stuff to put at the top of your kernel, why not go with a standard bunch of stuff and use a pre-existing format?

It's easier in the long term -- it's one less thing to worry about, and when you do see the need for some of the features that Candy lists, you'll get them for free.

[Pype.Clicker]

@Tim : agreed, as long as you have a powerful bootloader or a BOCHS by your side... i had none of them when i started. For about 3 years now, i have needed nothing else but those 4 fields to load my kernel.

The entry point (at least) is easy to enforce with a trivial linker script like

Code: Select all

    DWORD __start
    sections {
       ... .text, .data and the others
    }

That's a matter of preference: i KISS (keep it simple but not simpler) at the loader at the cost of a tool that translate COFF/ELF in SomethingElseILikeMore(tm). As that tool run in your development platform, it is easier to debug, you can inspect its result, etc.

As a bonus, i can use whatever development platform i whish (either COFF-based or ELF-based) rather than being 'bound' to use ELF because my bootloader says so, even if my compiler natively ignore it ...

marking parts of your executable as temporary: only ELF allows this, afaik. My latest attempt to create some 'custom' section (other than .text, .data or .bss) in a COFF-based version of GCC failed with a RTFM message.

protecting code from being modified: even in a flat binary, you can spice up your linker script with a code_end symbol. As the loaded kernel (and not the loader) is the one who enforces memory protection, there's actually no need for this information to be reported in a file format.

telling what went where: you still can ask the linker for a map of the binary object

get dissasembly with source lines embedded, etc: i generate a 'normal' object and *then* expunge it from anything not required (like lines numbers, etc), using the 'expunged' version for running, and 'full-fledged' version for debugging purpose (an offset within the binary can easily be resolved in an offset within a debugable object ... krash.pl exactly does this on demand for Clicker)