Re: Eclipse ARM toolchain for the Linux

ChrisQ <meru@xxxxxxxxxxx> writes:

John Devereux wrote:

I've just been through some of this too, just on a PC though not a
sparc! Of course for a PC there are lots of ready-made scripts on the
web, but that would be too easy. (And I wanted it without newlib, and to
experiment with lots of multilibs...).

Agree with the bit about too easy. Building the tools was a necessity
here, as there's nothing else available. Crossworks is available for
Solaris on intel, but I wouldn't think they would be too sympathetic to
a request for s sparc version, even if I were in the market to buy in a
toolchain. No, I wanted to get a bit more experience in the build
process and experiment with the various options. Now that I have all the
other gnu utilities in place, there is a reasonably good gnu build
environment in place and it should be easier to bootstrap later versions
in future.

The 3 or 4 issues with the newlib build were: 1 each in 2 crt0.S
modules, where I just commented out the offending lines. I always write
my own crto / startup code anyway, so that bit is irrelevant. The other
two were in two lib functions that I would never use anyway, so it
seemed safe to comment those out as well. Crude, but you have to start
by taking the pragmatic approach :-). After that, everything built fine.

Didn't build newlib within the 4.4.1 tree, as some docs I found on the
web suggest that you need to build gcc again after building and
installing newlib. If true, it probably means that newlib introduces
some dependencies into the gcc build process, which i'm not too happy
about. I see most if not all code here running from bare metal board
level, so binutils + gcc build should be all that's needed.

So what configure options did you use to experiment with lots of
multilibs and what were the results ?...

In fact the funny thing is that in the end I decided on not using
multilibs, and just configured for a cortex-m3 for the job in hand! But
I enjoyed experimenting. The multilib mechanism compiles separate copies
of the libraries for each combination and permutation of the arm target
flags. So at one point I had newlib being compiled something like 128
times, ending up with 128 libraries 10MB each. I decided this was not
the way forward...

Here are some notes I made, but use with caution since I am not an
expert! It is just what I discovered, sorry they are a bit jumbled.

Multilibs are configured in the gcc/config/arm/t-* files. These are
makefile fragments. These are strung together according to the target
triplet (“arm-non-eabi” etc) as per the script in gcc/config.gcc (in the
order defined there). (This script can be seen in action by examining
the output of the compilation process when building the toolchain). The
syntax is explained somewhat in the gcc internals document “target
makefile fragment” section. Also in the comment in the gcc/genmultilib
script. Before I found this information I cheated by cribbing from the
Code Sourcery distribution.

The codesourcery source code distribution contains specifications for a
more extensive set of multilibs than in the FSF tree.

These can e.g. be pasted into the t-arm-elf FSF file. Or just a
selection perhaps.

gcc/config.gcc is a shell script that configures which t- fragments are
used for a given target. So this is why arm-elf is different from
arm-none-eabi for example. It processes shell/environment variables such
as $target, $with_*. It “outputs” by setting variables such as

Main difference between arm-none-aebi and arm-elf seems to be that
arm-elf includes fragments “arm/t-arm-softfp soft-fp/t-softfp”.
(“soft-fp” is the name for gcc's generic software floating point
implementation.) But according to FSF t-arm-elf this is only used for
armv6-m. (Cortex M0/M1?). ieeelib is used for software FP for everything

So one can e.g. add the codesourcery file t-cs-eabi to the FSF
tree. Then patch config.gcc to include it (small patch to config.gcc

tm_file="$tm_file newlib-stdint.h"
tmake_file="${tmake_file} arm/t-bpabi"
+ tmake_file="${tmake_file} arm/t-cs-eabi"


John Devereux