Installation of the GNU tools

This page gives you help to set up the GNU crosscompiler toolchain for ARM processors.

It is assumed that you work on some unix-ish system, that is, BSD, Linux, MacOS-X or similar. If you use Microsoft^® Windows^®, you are on your own; my experience with that operating environment is limited to to Microsoft^® Word^® 1.0 and Minesweeper^® on Windows^® 3.1.

The process below tells you how to install the crosscompiler for a bare metal system. If you want to set up a crosscompiler for an ARM based Linux system, the process is much more involved and it is way beyond the scope of this manual.

Requirements

To set up the ARM crosscompiler toolchain, you will need the following packages to already having been installed on your system:

• gcc, the GNU C compiler for your system
• make, the build utility
• bison, the GNU parser generator
• flex, the GNU lexical analyser generator
• m4, the GNU macro processor
• libtool, a package to manipulate library installations
• gmp, the GNU multi-precision library, plus its headers
• mpfr, the multiple-precision float-point library, plus its headers
• texinfo, the info page formatting package

On a BSD or Linux system the above can usually be installed by simply telling your package manager to put them on (don't forget that you need the "development" package for gmp and mpfr). On MacOS-X it might be a little more complex than that, but a little research on the Web will help you through.

Installing cross-binutils

Download the binutils source from the FSF website or from a mirror. The following assumes that you have obtained binutils-2.20.1.tar.bz2 but the process is the same for any other version.
Unpack the source:

tar xfj binutils-2.20.1.tar.bz2

Do not go into the source directory. Create a separate build directry instead, then go there and configure binutils for arm-eabi target. If you prefer ELF over EABI, then use arm-elf instead of arm-eabi. If you have no idea what ELF and EABI are all about, you should first read ELF versus EABI at the end of this page and come back here.

mkdir build
cd build
../binutils-2.20.1/configure --target=arm-eabi

If configure did not complain about any missing packages, you can now build the binary utilities:

make

The above command should complete without error. Now you can install your crossassembler, linker, etc. Pretty much all GNU packages install in /usr/local by default, which is usually not writeable by ordinary users. So, you have to install as root, either by doing

sudo make install

or if you don't have sudo on your system, by becoming root (and, depending on your su configuration, going back to the build directory) and typing:

make install
exit

If the installaction succeeds, as it should, you should now get rid of the build directory:

cd ..
rm -rf build

Installing cross-gcc

Now that you have binutils installed, you are ready for the gcc installation.
Note that you must install binutils before you can compile gcc as it needs the already existing crossassembler and other tools to build the run-time library.
Also note that the instructions below allow you to install 4.0.x to 4.4.x versions of gcc. The 4.5.x or newer versions require additional packages, like a polyhedra library development package and alike to be installed.

Download the source rom the FSF website or from a mirror. The following assumes that you have obtained gcc-4.4.3.tar.bz2 but the process is the same for any other 4.[0-4].x version.
First, unpack the source:

tar xfj gcc-4.4.3.tar.bz2

Create a build directory and enter it:

mkdir build
cd build

Now configure to build a crosscompiler. There are a few configuration options that you have to pass. It wouldn't fit in a single line, so it is broken to multiple lines here, but it is a single command. Note that if you used arm-elf for binutils then you must use that for gcc as well.

../gcc-4.4.3/configure --target=arm-eabi --enable-interwork --disable-threads \ 
  --disable-tls --disable-libada --disable-libssp --disable-libgomp \
  --enable-languages=c

The command should finish without an error. If it complains about a package missing or being a too old revision, you will have to resolve that issue before being able to build the compiler. Assuming that configure finished successfully, you can build the crosscompiler:

make

It will take some time, several minutes (or several tens of minutes if you have some really old hardware) to complete. It should finish without any errors; although as it advances, you will see warning messages, but you can safely ignore them. When it's done, you can install it by:

sudo make install

just like you did with the binutils package. Get rid of the build directory before you forget:

cd ..
rm -rf build

To test that your install was really successful and everything is fine, you can try this:

echo 'void foo( void ) {}' > test.c
arm-elf-gcc -c test.c -o /dev/null

You should just get the prompt back, without any error messages. If that is the case, you have a working crosscompiler, you can compile the library, and of course your own stuff.

If you can not make up your mind regarding to the ELF vs. EABI issue, then you can install both, by going through the above configuration, compilation and installation procedure twice. When you are completely happy with everything, you can delete the source directories and the tarfiles:

rm -rf gcc-4.4.3* binutils-2.20.1*

ELF versus EABI

EABI stands for Embedded Application Binary Interface. It is basically a specification about register allocation, alignment rules, object sizes, calling conventions and so on. If your compiler conforms to the EABI, then the object code it generates will be usable by any other EABI compliant toolchain.

ELF stands for Executable and Link Format, a specification of how the object files and loadable executables are built. Among other things it is also an EABI, in that it specifies (most of) the conventions described by an EABI.

From your point of view both ELF and EABI are a specification of object size and alignment rules as well as register allocation and calling convention rules. Both will work. However, while they serve the same purpose, there are differences that you should be aware. Based on these differences you can make an informed decision about which one to use. The list below applies only to the 32-bit variants of ARM, for other processor architectures the rules are different!

• Common in both
  Both formats save R4-R11 through calls, use R13 as stack pointer, R12 as sratch, R0-R3 for parameter passing and R0 or R0-R1 for return value.
  The object sizes are also the same: char is 8 bits, short is 16 bits, int, long, float and pointers are 32 bits, long long and double are 64 bits.
  Both formats align 8, 16 and 32 bit wide basic types on 1, 2 and 4 byte boundaries, respectively.
  The stack grows from larger addresses to smaller ones (i.e. when you push, the stackpointer gets decremeneted), the stackpointer points to the last item pushed onto the stack (decrement before push, increment after pop).
  Object names are as they are in C, the compiler does not add any prefix or suffix to it.
  If a function receives a structure or union as argument, then the object gets copied onto the stack and the function argument will be changed to a pointer to the copy. If a function returns a struct or a union, then space will be allocated for the return object on the stack and the function will receive and extra argument (which will be the first), a pointer to the space where its return value should be stored. It is true even if the received or returned object would otherwise fit in a register.

• Endianness of 64-bit types
  Both ELF and EABI store a long long in the native endianness of the processor. However, a double is stored in Big-Endian word order in ELF and in the native endianness in EABI.
  When 64-bit objects are passed in registers, they are always placed in consecutive registers, like R0 and R1 or R4 and R5 but never like R2 and R7. The two registers are treated as if they were two consecutive memory locations. That is, if your object would be in memory words at addr and addr+4, then the word at addr will be in register Rn and the word at addr+1 will be in register Rn+1. This of course means that since on a Little-Endian machine the double is stored in different order for ELF and EABI, it will also be mapped to registers differently.

• Alignment of 64-bit types
  64-bit objects are aligned to 4 bytes in ELF and 8 bytes in EABI.
  That means that ELF simply treats them as two consecutive 32-bit words. On the other hand, EABI always aligns then on 8-byte boundaries. That applies to alignment of structure fields too. If you have a structure that contains an int followed by a double, ELF will put the double right after the int but EABI will introduce an additional word between them, to guarantee that the double starts at an 8-byte boundary.
  Furthermore, EABI always puts 64-byte objects into a register pair where the register corresponding to the memory word at the smaller address is an even numbered register, while ELF doesn't care. This means that if you have a function of which the first argument is an int and the second is a long long, then ELF will put the first argument in R0 and the second in R1-R2 while EABI will put the first argument in R0 but the second in R2-R3 and R1 will not ne used for argument passing. If you have a function that has a long long, an int and an other long long, then ELF will put the first argument in R0-R1, the second in R2 and the third will be split, one word will be in R3 and the other on the stack. EABI will pass the first two arguments in R0-R1 and R2, will not use R3 and pass the third argument on the stack. Eabi never splits a 64-bit object when passing it to functions.
  EABI's requirement of 64-bit objects always being aligned to 8-byte boundaries also means that it must maintain the stackpointer being 8-byte aligned when a function is called, which could lead to extra words allocated on the stack.

• Alignment of structures and unions
  ELF always aligns structures and unions to 4-byte boundaries and pads them to be a multiple of 4-bytes. EABI aligns and pads structures and unions according to the requirements of their members. Thus, if you have a struct that has a single char member, then ELF will align it to 4-bytes and put 3 bytes of padding into it. EABI will not pad it and will align it on 1-byte boundary. If you have a structure with a double and an int member, then ELF will not pad the structure and align it on a 4-byte boundary, while EABI will introduce a pad word and align the structure on an 8-byte boundary.

• Bitfields
  EABI defines bitfield treatment rules, but gcc does not conform to them (yet). ELF does not define them at all.

• Support
  It seems that ELF is treated as a goner by the gcc developers. According to the gcc people a CPU core and software where those alignment issues matter are, quote, "badly written code on antique hardware" and they couldn't care less about fixing bugs and issues specific to the ELF format for ARM. The standard response is "you should use EABI".

In conclusion, as long as you don't use double and long long, EABI is more memory efficient. If you use 64-bit objects, then EABI is clearly advantageous on architectures with wide buses, caches and so on, as it will not have to split a 64-bit transfer into two 32-bit ones. On a purely 32-bit core with no caches, such as the ARM7TDMI, EABI will waste memory (and under some circumstances, execution time) if you have lots of 64-bit objects. An other factor to consider is that ELF support is vaning, gcc developers do not react too positively to arm-elf- problems, they tell you to use EABI instead.