dclemans.falcon@mntgfx.mentor.com (Dave Clemans) (04/07/89)
To get GCC running on an Apollo system (with a Motorola M68k cpu)
you have to worry about a bit more than just getting a coff
format file. Most of this comes from the shared library system
used by the Apollo. On an Apollo system, there is no libc.a in
the traditional sense; the routines from libc.a are just always
"there" in your address space. The program loader handles the
connections basically transparently, however a certain coding style
is required. There is also a difference in calling sequences
for functions that return floating point numbers.
I now have GCC (using version 1.34) limping on the Apollo (Specifically
the compiler can compile itself, gcc, cccp and gas, but I have tested
it on very little else). The technique being used is an
"object file converter"; it takes the output of gas and generates
.o files suitable for the Apollo version of /bin/ld. It recognizes
the situations where the shared library is being used, or where
calling sequence changes are needed for floating point, and generates
appropriate patches. Normal Apollo system /usr/include files are used,
except where they need Apollo-specific C "extensions" to be removed.
I don't want to distribute this generally until more testing
has been done, but I'm willing to send out a couple of "alpha" copies.
(Note: the code currently just ignores and trashes symbolic debugging
symbols; this is one big area that needs work.) Contact me if interested.
A rough list of what the converter program does:
convert from a.out -> coff
convert relocation; for example a reference to a ".comm" symbol
must include the size of the symbol
Apollo coff doesn't support pc-relative relocation
nothing needing relocation must be left in .text after linking
relocate everything to fit in Apollo segment size boundaries
look for direct calls to shared library routines; build appropriate
.aptv entries (an Apollo specific coff section) and redirect the
call appropriately
look for direct "data" shared library references; for example uses
of errno; getting the address of a shared library routine, etc.
These are patched so that the code jumps to a "thunk" of code in
the .data section that the Apollo program loader can relocate.
Look for references to shared library routines that return floating
point numbers; they are patched to code in the .data section that
swizzles arguments correctly.
Generate a .sri section (another Apollo specific coff section) that
says what hardware/software requirements of the code are, desired
stacksize, etc.
Generate a .mir section (another Apollo specific coff section)
which is a comment section that says how the code was built.
Recognize "main" routines and patch in the appropriate startup code.
etc.
dgcvasta@apollo.COM (John Vasta) (04/12/89)
I suspect my postings on this subject didn't make it to the outside world; we've had problems with the news system last week. In article <1989Apr6.221259.8848@mntgfx.mentor.com> dclemans.falcon@mntgfx.mentor.com (Dave Clemans) writes: >To get GCC running on an Apollo system (with a Motorola M68k cpu) >you have to worry about a bit more than just getting a coff >format file. Most of this comes from the shared library system >used by the Apollo. On an Apollo system, there is no libc.a in >the traditional sense; the routines from libc.a are just always >"there" in your address space. The program loader handles the >connections basically transparently, however a certain coding style >is required. There is also a difference in calling sequences >for functions that return floating point numbers. > >I now have GCC (using version 1.34) limping on the Apollo (Specifically >the compiler can compile itself, gcc, cccp and gas, but I have tested >it on very little else). The technique being used is an >"object file converter"; it takes the output of gas and generates >.o files suitable for the Apollo version of /bin/ld. It recognizes >the situations where the shared library is being used, or where >calling sequence changes are needed for floating point, and generates >appropriate patches. Normal Apollo system /usr/include files are used, >except where they need Apollo-specific C "extensions" to be removed. I also have GCC running on the Apollo, supporting shared libraries and all our calling conventions. I also wrote an a.out-to-COFF converter which is embedded in GAS, the GNU assembler. However, in order to support shared libraries, I just put the code in a data section instead of the ".text" section, so that it is writable and therefore relocatable by the loader. No patching is needed. This means that code isn't sharable, but it was the easiest way to use the GNU compiler. Also, I changed the compiler to accomodate our differences in floating point calling conventions. These changes may appear in a future release of GCC someday. I also changed the GCC parser to accept the syntax extensions in our header files. In order to use these changes, you have to be running an SR10.x version of the operating system, with a bsd4.3 environment to build the GNU stuff. You'll need the distribution copies of GCC 1.34, GAS 1.31, and Bison. Ask me to send you the changes if you're interested. -- John Vasta Apollo Computer, Inc. CHA-O1-LT ARPA: vasta@apollo.com 330 Billerica Road, Chelmsford, MA 01824 UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta