Using and Porting GNU CC

4.3.4: `libgcc.a' and Cross-Compilers

Code compiled by GNU CC uses certain runtime support functions implicitly. Some of these functions can be compiled successfully with GNU CC itself, but a few cannot be. These problem functions are in the source file `libgcc1.c'; the library made from them is called `libgcc1.a'.

When you build a native compiler, these functions are compiled with some other compiler--the one that you use for bootstrapping GNU CC. Presumably it knows how to open code these operations, or else knows how to call the run-time emulation facilities that the machine comes with. But this approach doesn't work for building a cross-compiler. The compiler that you use for building knows about the host system, not the target system.

So, when you build a cross-compiler you have to supply a suitable library `libgcc1.a' that does the job it is expected to do.

To compile `libgcc1.c' with the cross-compiler itself does not work. The functions in this file are supposed to implement arithmetic operations that GNU CC does not know how to open code, for your target machine. If these functions are compiled with GNU CC itself, they will compile into infinite recursion.

On any given target, most of these functions are not needed. If GNU CC can open code an arithmetic operation, it will not call these functions to perform the operation. It is possible that on your target machine, none of these functions is needed. If so, you can supply an empty library as `libgcc1.a'.

Many targets need library support only for multiplication and division. If you are linking with a library that contains functions for multiplication and division, you can tell GNU CC to call them directly by defining the macros MULSI3_LIBCALL, and the like. These macros need to be defined in the target description macro file. For some targets, they are defined already. This may be sufficient to avoid the need for libgcc1.a; if so, you can supply an empty library.

Some targets do not have floating point instructions; they need other functions in `libgcc1.a', which do floating arithmetic. Recent versions of GNU CC have a file which emulates floating point. With a certain amount of work, you should be able to construct a floating point emulator that can be used as `libgcc1.a'. Perhaps future versions will contain code to do this automatically and conveniently. That depends on whether someone wants to implement it.

If your target system has another C compiler, you can configure GNU CC as a native compiler on that machine, build just `libgcc1.a' with `make libgcc1.a' on that machine, and use the resulting file with the cross-compiler. To do this, execute the following on the target machine:

cd target-build-dir
./configure --host=sparc --target=sun3
make libgcc1.a

And then this on the host machine:

ftp target-machine
binary
cd target-build-dir
get libgcc1.a
quit

Another way to provide the functions you need in `libgcc1.a' is to define the appropriate perform_... macros for those functions. If these definitions do not use the C arithmetic operators that they are meant to implement, you should be able to compile them with the cross-compiler you are building. (If these definitions already exist for your target file, then you are all set.)

To build `libgcc1.a' using the perform macros, use `LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the compiler. Otherwise, you should place your replacement library under the name `libgcc1.a' in the directory in which you will build the cross-compiler, before you run make.