Kernel Executable format

adw3221 · Post by **adw3221** » Mon Nov 13, 2006 5:20 pm

I am going to use virtual memory and paging for my OS and some people reccomended I use an executable format instead of plan binary. My operating system is going to be portible across architectures such as the i386+, 68020+, DEC Alpha, MIPS R4000+ and the PowerPC so I would like to keeps thins orginized.

I want to have virtual memory, paging, PNP and the like. I'm really considering taking the microkernel approch but a monlithic kernel is still on the table.

Right now my kernel is being compiled into plan binary format using JLOC. I'm using NASM 0.98 and Watcom C/C++ which at first were a pain to use but thanks to Ryu making an OBJ patcher for FIXUPP (They use the OMF object file) things run ok. I have no memory manager which brings me here. Because I'm using virtual memory and paging I'm going to have to relocate my kernel (its the most logical thing to do) however being the person that I am I like to plan things out in advance so I don't hit road blocks later on. The Watcom linker can do the MZ or PE executable format but I could use the GCC LD Linker (Does that accpect OMFs) for another executable format.

I'm also going to need to code my bootloader to load the kernel and when it comes to loading executables and relocation I'm lost.

If anyone can help me at all that would be great I'm really lost when it comes to this stuff

niteice · Post by **niteice** » Mon Nov 13, 2006 7:36 pm

I think ELF would be good, as the spec is open and it doesn't seem terribly hard to implement. Plus it's fully designed for portability.

adw3221 · Post by **adw3221** » Tue Nov 14, 2006 9:56 am

ELF sounds good then. I guess the GCC LD linker can output to that format? What input object files does it take?

gaf · Post by **gaf** » Tue Nov 14, 2006 1:26 pm

ELF sounds good then. I guess the GCC LD linker can output to that format?

In general you'll have to compile a gcc toolchain for OS development. Before building this compiler target platform and output-format can be choosen. GCC supports a wide range of architecures and should run on most of those mentioned by you. Choosing ELF as the file-format sounds like a reasonable idea.

a) Install Cygwin on your system
b) Create a toolchain for your target

I remember that we already talked about this some time ago (link). The precompiled binaries I uploaded back then should still be available if you want to avoid building it youself.

What input object files does it take?

Everything but OMF

The format is really old and never was much more than an extention to its 16bit predecessor. You might just update your compiler and use some more modern and powerful object-file format (ELF, COFF, PE). Have a look at the osfaq for a list of supported input formats.

Because I'm using virtual memory and paging I'm going to have to relocate my kernel

But your kernel already gets relocated to offset 0x10000 ? There are many reasons to use a proper binary-format but it's certainly not needed for virtual-addressing.

Why do you think that paging couldn't be used with a binary kernel ?

regards,
gaf

Candy · Post by **Candy** » Tue Nov 14, 2006 1:50 pm

gaf wrote:
What input object files does it take?
Everything but OMF

That's a pretty dangerous thing to say

TheQuux · Post by **TheQuux** » Tue Nov 14, 2006 2:02 pm

gaf wrote:
What input object files does it take?
Everything but OMF

RODFF?

smiddy · Post by **smiddy** » Tue Nov 14, 2006 2:14 pm

Unless you want to design in management of executeables, I would recommend a flatfile model, like a COM or similar, perhaps with a header that gives the expected memory needs and go from there. There's no need to get complicated unless you want to.

kataklinger · Post by **kataklinger** » Tue Nov 14, 2006 3:05 pm

Well it would be good for your kernel to be in some executable format if you want to export symbols from it (you can build kernel as DLL) and save some time.

carbonBased · Post by **carbonBased** » Tue Nov 14, 2006 8:06 pm

TheQuux wrote:
gaf wrote:
What input object files does it take?
Everything but OMF
RODFF?

You mean RDOFF[2]?

I don't believe ld supports this format, no. However, I've worked with the rdoff2 object format. It's pretty straightforward and simple (the design goal), so adding it into ld probably wouldn't be difficult.

--Jeff

adw3221 · Post by **adw3221** » Wed Nov 15, 2006 11:08 am

Wow thank you I will look into these. Is there an object library convertor?

carbonBased · Post by **carbonBased** » Thu Nov 16, 2006 12:59 pm

Mike359 wrote:Wow thank you I will look into these. Is there an object library convertor?

objcopy can be used to perform some format conversions. This is available on most linux distributions, and probably most cygwin distribs, as well.

--Jeff

martin.zielinski · Post by **martin.zielinski** » Fri Nov 17, 2006 2:32 am

I you're developing on windows, it should be most conveniant to use the PE format. This can be easily loaded by your booloader and a bit easier by grub.

I've built an PE loader into my os-project too and it makes the development workflow a lot smoother when you can work with the tools that you are used to, and not with tools that you _must_ choose because of a specific needed output format. In my opinion this should be the most importent base for the decision which binary format you want to use. Base it on the tools you are conveniant with and which your are used to, and than invest the little work to load your choosen format as is.

This will be the right thing in the long run.

carbonBased · Post by **carbonBased** » Fri Nov 17, 2006 10:23 am

martin.zielinski wrote:I you're developing on windows, it should be most conveniant to use the PE format. This can be easily loaded by your booloader and a bit easier by grub.

I've built an PE loader into my os-project too and it makes the development workflow a lot smoother when you can work with the tools that you are used to, and not with tools that you _must_ choose because of a specific needed output format. In my opinion this should be the most importent base for the decision which binary format you want to use. Base it on the tools you are conveniant with and which your are used to, and than invest the little work to load your choosen format as is.

This will be the right thing in the long run.

While I definitely agree with your logic, I'd just like to toss out there that, imo, ELF is superior to PE. If ELF interests you, you might want to start with PE and then transition to ELF (forgive me if this is what your last point is saying, I wasn't entirely sure).

Cheers,
Jeff

Combuster · Post by **Combuster** » Fri Nov 17, 2006 5:19 pm

PE is a complex beast, and for what i've seen the documentation isnt really good. ELF however has a good formal specification, and compared to PE its relatively easy to use. The app that loads, relocates, and starts ELF executables in my os is just over 1.8kb

If you're used to GCC, you can build an ELF cross-compiler in 15 minutes.

As for the tool argument, some IDEs allow you to choose/configure for a specific compiler/target. If you are used to Visual Studio however, then you might indeed want to stick to PE as its afaik the only thing it'll do properly.

JAAman · Post by **JAAman** » Fri Nov 17, 2006 5:44 pm

As for the tool argument, some IDEs allow you to choose/configure for a specific compiler/target. If you are used to Visual Studio however, then you might indeed want to stick to PE as its afaik the only thing it'll do properly.

correction:
PE is the only format the MS compiler/linker will easily handle

if you want, you can use the visual studio IDE with GCC or any other command line compiler