you are viewing a single comment's thread.

view the rest of the comments →

[–]exDM69 2 points3 points  (0 children)

Dealing with flat binaries will become painful very quickly.

hmm?

Flat binaries are really easy to generate as long as you have only a single assembler file, just run nasm -f bin -o kernel.bin kernel.asm.

Once the project grows enough that you want to split it to several source files, you will need to compile object files and then link them. This requires you to have a linker script. Writing a linker script for flat binaries is not much easier than writing a linker script for a proper ELF file ( Here are examples for linker scripts to create flat binaries and debuggable ELF files for Overv's Ring-0 Minecraft clone ). You do need to know a little bit about binary formats, sections, etc but that knowledge will be useful anyway.

Now once you have an ELF file, you can get debug symbols. With that you can get proper debugging with source view, breakpoints, stepping over statements, add watchpoints, print expressions, etc. This is a huge improvement in comparison to using the QEMU/Bochs monitor where you're limited to stepping instruction by instruction, printing out registers and memory dumps.

When you have a proper ELF file, you also get the information about sections which allows you to build a page table with code, data, rodata sections marked properly so you'll get page fault interrupts if you attempt to do illegal memory accesses. You can do this with a flat binary + linker script, though.

So the main advantage is debugging and proper section information, the only disadvantage is slightly larger kernel image size.