Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ncoast.org!allbery
From: allbery@ncoast.org (Brandon S. Allbery)
Newsgroups: gnu.gcc
Subject: shared source question
Message-ID: <8906071323.AA16738@NCoast.ORG>
Date: 7 Jun 89 13:23:09 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 29

In your message of Tue, 06 Jun 89 20:31:49 PDT, you write:
+---------------
| No doubt GNU LD could be modified to handle compound executables, or a separate
| utility could be used to produce them from individual architecture-specific
| executables.  The problem, however, is that the kernel must be modified to
| understand how to select and run the correct executable from a compound
| executable.  So|  when there is a GNU kernel, adding this support could be
| done rather easily I expect; without source to the kernel, there's no way
| to do this.
+---------------

I know about the kernel needing to know what's going on.  My thought was that
it might be possible to arrange for the kernel to use a different entry
point depending on the processor; the COFF header structure seems to have some
hooks for this, although they aren't quite good enough for the real world
(which is probably why AT&T's now pushing this new ELF format).  And in
these days of heterogenous networks, maybe someone should push for such a
capability in BSD4.4.

Of course, I could probably figure out for myself whether this would work or
not if I knew what BSD uses for an executable header on various machines....

I suggested it because I seem to remember hearing something about a
technique Sun was using to get SPARC and Sun3 executables for SunOS4.0 into
the same exectable file; this is exactly what we're looking for.  Of course,
if Sun put special hooks into the SunOS4 kernel to do this, it's no help;
but I was betting on Sun retaining as much BSD compatibility as possible.

++Brandon