[coyotos-dev] Executable format for Coyotos

[Jonathan S. Shapiro]

We were talking about something close to this just the other day.

Since we don't have a native-hosted compile tool chain yet, it's hard to
predict what that will do. The easiest path will certainly be to
duplicate what we have done in the cross-compile tool chain, so let me
describe that.

We have considered building a fault handler that faults in mappings from
ELF binaries on demand. It can be done, but we don't currently have
plans to do it, because there isn't really any need. It's easier for a
post-linker to simply construct the needed space directly. This lets the
fault handler be completely object-format neutral. This neutrality will
start to break down when we need to deal with thread-local storage.

Today, the cross-compile tool chain currently generates conventional ELF
binaries. The mkimage tool then picks these up and builds memory spaces
from them. The run-time page fault handler knows nothing about binary
images at all.

The other day, Jonathan Adams and I were talking about ideas for
debugging support. At the moment, the plan is that mkimage will build
*two* address spaces: one containing the raw elf image and the other
containing a populated address space. These spaces will share many
pages. We aren't yet implementing this.

For native-mode applications, there isn't anything I see at the moment
that would prevent doing this for COFF, XCOFF, etc (in fact, EROS
mkimage handled both ELF and a.out), but it seems like a lot of effort
for minimal gain. The *COFF formats are less expressive than ELF, and it
would be significant effort to re-target a cross-linker to these
formats.

However, this may change very shortly. We are considering how a
native-mode program should declare the variables that live in capability
space, and this will require making use of the section extensibility of
the ELF format. *COFF, so far as I know, doesn't have this type of
extensibility.

If your goal is to emulate existing runtime environments for other OS's,
I don't see anything that would be a problem. You could either implement
a binary-format-aware fault handler or hand-construct a space from the
binary image using a post-link tool. Either approach should work.

For native-mode execution, I'ld plan to stick to ELF.


shap



On Sat, 2007-03-03 at 03:00 +0100, Pierre THIERRY wrote:
> Will there be a needed for a primary executable format in Coyotos, or
> some applications could safely use their own, as process creation is
> easier to do than in other OSes?
> 
> I mean, there could be a constructor template for ELF files, another for
> COFF, XCOFF or ECOFF ones, and so, couldn't it?
> 
> Curiously,
> Pierre
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100