Xref: utzoo comp.sys.apollo:2504 gnu.gcc:455
Path: utzoo!utgpu!watmath!uunet!tektronix!sequent!mntgfx!dclemans.falcon
From: dclemans.falcon@mntgfx.mentor.com (Dave Clemans)
Newsgroups: comp.sys.apollo,gnu.gcc
Subject: GCC & the Apollo
Message-ID: <1989Apr6.221259.8848@mntgfx.mentor.com>
Date: 7 Apr 89 05:12:58 GMT
Organization: Mentor Graphics Corporation, Beaverton Oregon
Lines: 63

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.

dgc