Eclipse ARM toolchain for the Linux

I thought it was about time I reported back on the openocd and tools build.

The openocd build effectively worked out of the box and I borrowed a j-Link to test with. Installed the latest Debian squeeze on an old T30 laptop, compilers etc and it all builds and seems fine. Either insight

6.1 or 6.8 on the Solaris 10 / sparc box can see it at the other end of the wire, though not tested with real code yet.

Then spent quite a bit of time building the late rev gnu toolchain cross from Sol10 / sparc to arm, as earlier versions that I have don't support cortex. To start with, all relevant later versions of gcc need the gmp and mpfr math libs to build at all. Initially tried to build these from source, but all the make tests failed. Fortunately, sunfreeware.org has package binaries. If you go to 4.5.2, you also need the mpc lib, but more on that later.

Had a few configure and build issues to start with. Things like gmp and mpfr include, lib, file paths and the ld environment variable for the local shell, but now have 4.1.0 and 4.4.1 cross builds completed in separate trees. The latest binutils 2.21 configures, builds and installs with only a couple of minor warnings, which is great and once you have all the prerequisites in place, both gcc revs build fine as well, though with a lot more minor warnings. Also have a version of newlib built in the 4.1.0 tree, but that required hack (to look at later perhaps) commenting out sections of code to get the build to work. They are all in areas not relevant to the work here and don't expect to be using newlib much, but did the build more out of curiosity as to what problems would arise. If you are wondering why the gcc 4.4.1 rev was built, it's needed to support cortex m3 etc.

4.5.2, the latest rev, is another issue altogether and it's needed to support later cortex versions like m0 and m1. The MPC lib is a new prerequisite and there are no binary packages available for sol10/sparc, afaik. So, build from source and again, all 57 tests segfault fail on make tests. As i'm unlikely to need any of this math stuff for embedded, have a go at configure for 4.5.2 anyway. Configure reports gmp, mpfr and mpc as "buggy but acceptable", but compile eventually stops with a fatal error. Will be having another look later, but no time at the mo, as I want to get some real code running on a target m3 board. The whole point of the exercise in the first place :-).

Various things emerge from all this. The first is that gnu source quality has vastly improved over earlier revs, with far fewer warnings during build. The downside is the growing list of prerequisites just to build gcc at all. Looking at some of the sources, it's amazing that it even works, such is the complexity now, but hats off and many thanks to all the people who make it possible.

If anyone here would like a binary tarball of either build tree, or just tool binaries and libs, please let me know. While I guess it's a little perverse to be running sparc boxes, the cpu gene pool diminishes more every year and you have to make a stand at some stage. They are also just nice, quality systems to work with...

Regards,

Chris

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...).

I know what you mean about the prerequisites, they seem to add another one each time I look at it.

[...]

--

John Devereux

I am curious what you used instead of newlib (or did you roll your own replacement functions) ?

I've been building ARM GCC cross compiler toolkits recently as well and I am just making sure there isn't some option available which I am not aware of. :-)

Indeed. It was a lot quicker to build a toolkit back in the gcc 3.x days. :-)

To be fair however, all the prerequisites do build and pass their tests without any problems for me.

On the plus side, I have noticed the recent versions of gcc have become a lot stricter about certain C code constructs as some versions of open source packages which built under earlier versions of gcc needed changes to build under later versions. (No, I don't have any examples to hand unfortunately.)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

The latter!

I was finding that the infrastructure of newlib was more trouble than it was worth, for me. A careless assert() in a bootloader brought in most of stdio etc.

I mainly just wrote a few easy things like memset, strlen etc, as required. A trivial allocate-only "malloc".

There is also a public domain reduced printf that I customized with special conversion codes for "fixed decimal point" numbers. Quite pleased with that.

Not really, I didn't have a 4 core hyperthreading machine then :)

make -j 12

... speeds things up no end.

--

John Devereux

That I can _easily_ believe. :-)

Interesting. As my professional programming area involves business coding, fixed point calculations are something I am familiar with and I have thought about creating a fixed point library as a way of implementing non-integer calculations in a upcoming ARM project without having to pull in a software floating point library.

BTW, I've also seen references to newlib been used by a cross compiled gcc itself, including in the generated code for various low-level functions, but I have not investigated for myself yet.

Did you have any problems in this area ?

:-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

It simply adds letters to the format string so I can do things like

fmt(lcd, "Test Time %6.3m seconds", milliseconds);

Where the "m" could be d, c, m for deci- centi- milli.

The output would then be

Test Time 12.345 seconds

Of course there are other ways to do the same thing.

Actually, isn't there an extension to the C language for fixed point arithmetic too? Wouldn't trust it for financial work though :)

It seems to be needed for c++, but not a plain C compiler AFAIK. That just seems to use libgcc2. I gather gcc can optimise certain contructs into library calls ("builtins"). Perhaps a loop through an array that zeroes each element could be replaced by memset. I have not hit this myself yet, perhaps I have not enabled the right optimisations or I have already written the functions required!

[...]

--

John Devereux

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 ?...

Regards,

Chris

You can also work in scaled integers for some apps. On a cash handling machine from many years ago, all the values were stored in pence. The resulting math was quite trivial, as was conversion for display. I was very gratefull for decimalisation at the time. U32 had more than enough range to handle max values.

Imagine having to do all that in pounds / shillings and pence. Eeeek !.

Interesting - see other post to john re this issue, but haven't looked into what the dependencies are, if any...

Regards,

Chris

Have no real knowledge of gdb internals, but are the various debug protocols now handled by some sort of plug in format, or is it an ad hoc function call interface ?. A plug structure would make the integration of alternate debug formats easier as it would become more of a translation process, from internal format to and from target...

Regards,

Chris

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 $tmake_file

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 else.

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 below).

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

+ tmake_file="${tmake_file} arm/t-cs-eabi" use_gcc_stdint=wrap ;; arm*-*-symbianelf*)

--

John Devereux

I have just checked and it appears to have been added to gcc over the last few years although it does appear to be a work in progress.

In my defence, I am still at the thinking about it stage, and hopefully I would have found this if[1] I moved into the actually implementing it stage.

[1] "If" because I am also seriously thinking about getting Ada to run standalone on a bare ARM board as I have used it on larger boards under RTEMS and Ada has fixed point support built in as part of the language.

And no, you would not catch me using C for financial work, even with these extensions. In my day job, although I use C for various things, I use another language for the financial/accounting code.

Interesting that you have not encountered this yet.

I got the impression that the required functions were at a lower level than things like memset(), like, for example, internal support for various math and type conversion functions.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

gcc has an ada front end too doesn't it?

Visual COBOL++#.NET ? haha

Pretty sure these are in gcclib, part of the gcc tree rather than newlib AFAIK.

--

John Devereux

Yes, it does but Ada has more platform specific requirements (due to it's RTL and general language features) than C does.

What I don't yet know is how much work is involved in making those Ada specific features work on a bare board. (But I'm looking forward to finding out as and when real life allows me. :-))

No way. :-)

You won't catch me running Windows for server type applications.

I use a combination of VMS and Linux in my day job.

You may be right - this is at the limits of my current knowledge of the gcc toolchain (at least for the moment).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Took you tip and downloaded the Codesourcery source tree earlier and compared their t-cs-eabi with the 4.4.1 t-arm-elf used in the build here. Their file looks like it will handle just about every arm version known to man, which is to be expected, whereas the 4.4.1 arm-elf file has few entries, just generating generic (?) arm and thumb libs by default. I uncommented the following 4 lines in 4.4.1 t-arm-elf:

MULTILIB_OPTIONS += march=armv7 MULTILIB_DIRNAMES += thumb2 MULTILIB_EXCEPTIONS += march=armv7* marm/*march=armv7* #MULTILIB_MATCHES += march?armv7=march?armv7-a #MULTILIB_MATCHES += march?armv7=march?armv7-r #MULTILIB_MATCHES += march?armv7=march?armv7-m #MULTILIB_MATCHES += march?armv7=mcpu?cortex-a8 #MULTILIB_MATCHES += march?armv7=mcpu?cortex-r4 MULTILIB_MATCHES += march?armv7=mcpu?cortex-m3

fwics, this has the effect of appending thumb2, cortex-m3 libs to the build process. Correct me if wrong :-).

After configure and rebuild, there is a thumb2 directory appended to the original thumb lib dir with the thumb2 libs in place. Needs code to test, but perhaps another bit of the puzzle may be in place...

Regards,

Chris

GCC needs access to some C library headers when it's built, but you need a working crosscompiler for newlib's build process to generate and install those headers. To solve this dependency loop you usually build a special version of GCC first (configured with --without-headers), use that compiler to build newlib and then build the final compiler.

-a

There are some other differences between the two ABIs as well, including the syscall interface and structure packing. I swear I had a document detailing the differences, but I seem to have lost it. In any case, eabi is considered the "current" ABI, elf is more or less obsoleted.

-a

Thanks for the correction, my notes were focussing only on the multilibs aspect.

(For my own applications the syscall interface does not matter but the structure packing might).

--

John Devereux

That's very helpfull, thanks. I remember building 2.95 or thereabouts for 68k some years ago and had to manually copy some include files which were not part of the gcc distribution to get gcc to build...

Regards,

Chris