[2583] in Release_Engineering
Issues in porting NEOS to DECMIPS
daemon@ATHENA.MIT.EDU (Bill Cattey)
Wed May 1 15:31:41 1991
Date: Wed, 1 May 1991 15:30:46 -0400 (EDT)
From: Bill Cattey <wdc@ATHENA.MIT.EDU>
To: rel-eng@ATHENA.MIT.EDU, geer@crl.dec.com, koolkin@ATHENA.MIT.EDU,
As some of you may know, I hope to offer our EZ based NEOS in a future
release of Athena software.
There is work afoot to distribute NEOS, the command line half on the
Athena PANSS tape, and the EZ based half on the Andrew tape from CMU.
I have started work on doing an Alpha test of the distribution to North
Carolina State University. (Which currently runs exclusively with
DECMIPS hardware.)
There is a problem. To quote the Andrew build document:
> The MIPS compiler tools have a notion of a global area into which small
> data items are allocated. This allows the compiler to generate
> small-offset addresses for these items, which gives better performance.
> By default, any item eight (8) bytes or smaller gets allocated into this
> area. Unfortunately, the global area mechanism clashes horribly with
> the way dynamic loading works. The problem is that the global area is
> fixed in size at link time and cannot be expanded at run time.
> Therefore if a dynamic object (.do file) contains any data that must go
> in the global area, the object cannot be loaded.
> In order to get around this problem, all code that goes into .do files
> must be compiled with the "-G 0" switch. For source code shipped in the
> Andrew distribution, this is not really a problem, since we just compile
> everything -G 0. However, one must also provide -G 0 versions of
certain system libraries as well.
Most sites will be running current Ultrix releases which means that
libc.a and libm.a will be available -G0.
Because of the large number of services and libraries used by the
EZ/NEOS combination, sites like NCSU will have to re-compile the
following -G0:
X11:
libX11.a
liboldX.a
PANSS:
libhesiod.a libkrb.a libss.a libcom_err.a libdes.a
AFS:
liblwp.a librx.a librxkad.a libubik.a
libacl.a libbudb.a libdir.a libprot.a util.a
libafsint.a libbutm.a libfsprobe.a libsys.a vlib.a
libauth.a libbxdb.a libgtx.a libtermlib.a
libbos.a libcmd.a libkauth.a libvldb.a
libbubasics.a libcom_err.a libnull.a libvolser.a
The X11 and PANSS components will be inconvenient. The AFS components
may be impossible for sites without AFS source.
----
This poses challenges for our own release engineering and for our export
of the Project Athena Network System Services.
How will release engineering deal with having to compile all these
libraries twice?
Can we expect sites to opt out of using screen oriented NEOS due to the
added inconvenience?
----
As I see it the options are:
Inconvenience all sites by forcing them to compile everyting twice.
Lobby Transarc, the X consortium, and our own PANSS tape makers to set
up the Makefiles to build G 0 versions of everyting and, in the case of
Transarc, to ship G 0 versions to DECMIPS sites that are binary-only.
Hire some expert on object file postprocessing to build a filter program
that will mung standard DECMIPS binaries and remap use of the global
area.
----
How can we deal with this situation?
Is there some way we can improve it?
-wdc
