Steps to build an OS, am I doing it right?

[Kevin]

Putting the OS at raw sectors is also possible, although a little awkward.

Indeed. In my experience, one of the most common mistakes that newbies make with their quick hack that they call a boot loader is that they load only n sectors and don't notice when the kernel grows to n+1 sectors. To fix it, some even just increase it to m sectors and come back asking for help when the kernel reaches m+1 sectors...

A custom boot-loader definitely doesn't need to know file formats, unless the OS creator never heard binary file formats.

Using ELF for the kernel has its advantages. Debug information, symbols available at runtime, stuff like this. Yes, I guess you can work around it. But... why not just use a file format that provides it from the start?

[Combuster]

A custom boot-loader definitely doesn't need to know file formats, unless the OS creator never heard binary file formats.

A flat file is still a format. The only difference is that the headers you "got rid of" are now magic numbers in the bootloader code.

[Yoda]

Flat binary format is inevitable somwhere as intermediate step between ELF and first stage boot loader.

[rdos]

Using ELF for the kernel has its advantages. Debug information, symbols available at runtime, stuff like this. Yes, I guess you can work around it. But... why not just use a file format that provides it from the start?

Yes, but it is better to have the symbols in a separate file rather than in the kernel image itself.

[rdos]

Flat binary format is inevitable somwhere as intermediate step between ELF and first stage boot loader.

It depends how we define "flat binary". If you also include a real-mode loader, you are right. If you mean a 32/64 bit flat binary, no. That is not necessary. It is not even necessary to have kernel in ELF or PE. There are alternatives (including own header definitions which I use).

[Kevin]

Yes, but it is better to have the symbols in a separate file rather than in the kernel image itself.

For using them with an external debugger, like wih a gdb stub, probably a matter of taste (and for those using floppies, potentially of disk image size).

For actually using them in the kernel at runtime, like for backtraces or loading modules, I can't see why having them in a separate file would be a good idea.

[bluemoon]

Yes, but it is better to have the symbols in a separate file rather than in the kernel image itself.

I suppose you know that the symbols & debug info can be strip into another file.

I do this to my kernel binary (ELF32/ELF64)

Code: Select all

$(KERNEL_BIN): $(KERNEL_TMP) $(KERNEL_OBJ) $(KERNEL_USELIB) Makefile
	@echo [LINK] $@
	@$(LD) $(LDFLAGS) -Tarch/$(ARCH)/kernel.ld -o $@ $(KERNEL_OBJ) $(KERNEL_USELIB)
	@$(OBJCOPY) --only-keep-debug $@ $(KERNEL_SYM)
	@$(OBJCOPY) --strip-debug --strip-unneeded $@

[FallenAvatar]

Yes, but it is better to have the symbols in a separate file rather than in the kernel image itself.

I suppose you know that the symbols & debug info can be strip into another file.

I can't believe I am saying this, but I agree with rdos (Hell froze over? haha)

This has been a default/feature/whatever of microsoft compiliers/linkers for a while. They use a seperate file (*.pdb) that contains the debug info. This has some advantages, if your kernel code has all of 1-3 extra lines of code, its easy to ignore missing debug info, and then just delete them from releases. This CAN be easier to maintain (but is not be default). It also has the advantage of giving you, the developer, a realistic idea of the size of a binary file (ie. without debugging info) And this plays nice with both local and remote debugging techniques.

However, this does require extra code to load the debug info when it is present, and may not be feasible in early stages of development.

So, both ways work, both ways make "sense" and both ways have pros/cons. This really comes down to personal preference/experience.

- Monk

[Kirk]

I think the OP hasn't grasped the very basics. Read James's tutorials:

http://www.jamesmolloy.co.uk/index.html