RE: porting gcc/binutils

["Meissner, Michael" <michael dot meissner at amd dot com>]

When I used to work for Cygnus Solutions (and then Red Hat after they
bought Cygnus in 1999), the general port to an embedded target was
typically done in parallel by 3 people (or 3 groups for large ports).
Before starting out, somebody would design the ABI (either customer
paying for the port, the person doing the compiler port, or some
combination of the two).  Also, the object file and debug formats were
chosen, ELF and Dwarf was the default choice, unless there was some
overriding reason to use something else.

The first parallel part of the port was porting gas and then ld.  You
need to look at the machine and determine what object file relocations
are needed.  If you were using ELF, in theory you would reserve the
appropriate magic numbers with SCO so that there would be no conflicts,
but a lot of ports didn't do that.  I may have been one of the last
people to get an official E_xxx number (E_SEP) before SCO started on its
current self destructive path.

As the assembler/linker work is started, the compiler person/team would
begin work.  Most ports are done by cloning another port, and often
times you can find places where the original comments were not modified.
When I did my second port from scratch, I set out to write a generic
backend that had all of the options as comments.  Unfortunately, the
port had decayed since it was not kept up to date, and is probably less
than useful, even if it had been released outside of Cygnus/Red Hat.
Obviously, after the initial definition, you will need the assembler and
linker to complete the compiler.

After the assembler/linker is done, the person/team doing that usually
would work on the simulator, and the simulator will be needed for the
second stage of compiler debugging (once everything builds).  If you
have the machine available in silicon form, then you can skip this step.

If your target is a regular target like a RISC platform, the CGEN system
can be used to simplify building the instruction tables:
http://sourceware.org/cgen/

The compiler team does all of the initial work.  By the time the
compiler can build stuff, either the compiler or binutils team will
create the system specific parts of newlib to handle I/O, etc. on the
simulator or hardware.

Once programs can be built and linked, the debugger team does whatever
is needed to bring up gdb.  Often times, the debugger would trail the
compiler, and the initial part of debugging the compiler was done via
simulator traces.

Running hello world is a milestone.  First you write it using the write
system call, and in the second iteration you rewrite it using printf.

The next milestone is running a full make check on each of the tools,
adding specific machine support for the assembler, linker, etc.

Usually after the compiler system is up and running, you start looking
into adding shared library support, new optimizations, etc.

For a lot of embedded chips, the next step is porting Linux or BSD to
the chip.

By then you need to start porting the applications that will be run on
the target, and fixing bugs, adding new optimizations, etc.

If you are the only person doing the project, I would do assembler,
linker, simulator, compiler, newlib, debugger, finish compiler port,
port Linux....

If you intend to have the port contributed to the FSF, be sure you start
your paperwork early.  If you are being paid for the work, you will need
signatures from the appropriate corporate officers to verify that you
are legally allowed to contribute the code.  If you are doing this in
your spare time, make sure you know what your legal status is for code
that you write.


-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Andrija Radicevic
Sent: Wednesday, December 14, 2005 6:31 PM
To: gcc@gnu.org
Subject: porting gcc/binutils

Hi,

I'm trying to port gcc and binutils to a new target and I hoped to find
a brief procedure on that matter on the net, but was unsuccessful. OK,
the GCC internals is quite a resourceful document and one can learn a
lot by examining the source tree, but It would be very helpful if there
would be a brief procedure description (HOWTO). Like what to do first,
port gas I guess, and what to do (like create your directory(s), write
ISA file(s), machine descriptions, coff/elf generation etc.).
I'd be really grateful if someone could help me out.

best regards

Andrija Radicevic