[coyotos-dev] Executable format for Coyotos

[Jonathan S. Shapiro]

On Sun, 2007-03-04 at 23:42 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 04/03/2007 hora 17:25:
> > I think you don't understand how the bootstrap works.
> 
> Probably. Fortunately I showed it.
> 
> > It isn't the constructor's job to fabricate a program from a binary
> > image. That is the job of mkimage.
> 
> Say I have a running Coyotos system. On this system, I have a working
> BitC compiler, or Common Lisp compiler. I write a program, and make an
> executable of it for other users to be able to use it.
> 
> I thought that would involve creating a binary file and sealing a
> constructor with at least authority to read that file. And that when
> asked to instantiate my program, the constructor, from data in the
> binary file, would make a process of it.

Close, but you are missing a step. Perhaps two. There is an additional
step after the linker has produced the executable.

For a self-hosted build, you would now run an additional tool. This tool
extracts the loadable sections from the executable file and copies them
into their proper positions into a new address space. This address space
is what gets installed into the constructor (i.e. not the executable).

For a cross-hosted build, the end result is similar, but the mkimage
tool builds the space for you.

> Much a when the loader in a Unix system creates a process from a *COFF
> or ELF file. Except that because you aren't forced to have a single
> constructor in Coyotos, you could as well use a different binary format
> in different cases.

I think what you are missing is that address spaces are persistent, so
there is no reason to do this step every time a program is started.
Instead, we do it *before* the constructor is created. We then have a
pre-existing, pre-loaded space that is used in copy-on-write fashion.

Because you (the developer) run a tool to fabricate the space, it
*should* be readily possible to build an equivalent tool for non-ELF
binaries. I'm not immediately clear why you would want to avoid the
built-in tool chain, but you could do it. You could also emit code
directly into a target address space.