Porting GCC requires two things, neither of which has anything to do with GCC. If GCC already supports a processor type, then all the work in porting GCC is really a linker issue. All GCC has to do is produce assembler output in the proper syntax. Most of the work is done by the linker, which is described elsewhere.
Mostly all GCC does is format the command line for the linker pass. The
command line for GCC is set in the various config subdirectories of gcc.
The options of interest to us are CPP_SPEC and
STARTFILE_SPEC. CPP_SPEC sets the builtin defines for your
environment. If you support multiple environments with the same
processor, then OS specific defines will need to be elsewhere.
STARTFILE_SPEC
Once you have linker support, GCC will be able to produce a fully linked executable image. The only part of GCC that the linker wants is a crt0.o, and a memory map. If you plan on running any programs that do I/O of any kind, you'll need to write support for the C library, which is described elsewhere.
GCC by itself only compiles the C or C++ code into assembler. Typically
GCC invokes all the passes required for you. These passes are cpp, cc1,
gas, ld. cpp is the C preprocessor. This will merge in the
include files, expand all macros definitions, and process all the
#ifdef sections. To see the output of ccp, invoke gcc with the
-E option, and the preprocessed file will be printed on the
stdout. cc1 is the actual compiler pass that produces the assembler for
the processed file. GCC is actually only a driver program for all the
compiler passes. It will format command line options for the other passes.
The usual command line GCC uses for the final link phase will have LD
link in the startup code and additional libraries by default.
GNU AS started it's life to only function as a compiler pass, but
these days it can also be used as a source level assembler. When used as
a source level assembler, it has a companion assembler preprocessor
called gasp. This has a syntax similar to most other assembler
macros packages. GAS emits a relocatable object file from the assembler
source. The object file contains the executable part of the application,
and debug symbols.
LD is responsible for resolving the addresses and symbols to something
that will be fully self-contained. Some RTOS's use relocatable object
file formats like a.out, but more commonly the final image will
only use absolute addresses for symbols. This enables code to be burned
into PROMS as well. Although LD can produce an executable image, there
is usually a hidden object file called crt0.o that is required as
startup code. With this startup code and a memory map, the executable
image will actually run on the target environment. section Crt0, the main startup file.
The startup code usually defines a special symbol like _start
that is the default base address for the application, and the first
symbol in the executable image. If you plan to use any routines from the
standard C library, you'll also need to implement the functions that
this library is dependent on. section Porting newlib.
Options for the various development tools are covered in more detail elsewhere. Still, the amount of options can be an overwhelming amount of stuff, so the options most suited to embedded systems are summarized here. If you use GCC as the main driver for all the passes, most of the linker options can be passed directly to the compiler. There are also GCC options that control how the GCC driver formats the command line arguments for the linker.
Most of the GCC options that we're interested control how the GCC driver formats the options for the linker pass.
-nostartfiles
-nostdlib
-Xlinker
-v
-fpic
Go to the first, previous, next, last section, table of contents.