Eclipse ARM toolchain for the Linux

ChrisQ <meru@devnull.com> 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 (&ldquo;arm-non-eabi&rdquo; 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 &ldquo;target
makefile fragment&rdquo; 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 &ldquo;outputs&rdquo; by setting variables such as
$tmake_file

Main difference between arm-none-aebi and arm-elf seems to be that
arm-elf includes fragments &ldquo;arm/t-arm-softfp soft-fp/t-softfp&rdquo;.
(&ldquo;soft-fp&rdquo; 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

On 2011-03-14, John Devereux <john@devereux.me.uk> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
> Actually, isn't there an extension to the C language for fixed point
> arithmetic too? Wouldn't trust it for financial work though :)
>

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.

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

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

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2011-03-14, John Devereux <john@devereux.me.uk> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> Actually, isn't there an extension to the C language for fixed point
>> arithmetic too? Wouldn't trust it for financial work though :)
>>
>
> 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.

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

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

Visual COBOL++#.NET ? haha

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

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

-- 

John Devereux

On 2011-03-14, John Devereux <john@devereux.me.uk> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> [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.
>
> gcc has an ada front end too doesn't it?
>

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

>> 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.
>
> Visual COBOL++#.NET ? haha
>

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.

>>
>> 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.
>
> Pretty sure these are in gcclib, part of the gcc tree rather than newlib
> AFAIK.
>

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

John Devereux wrote:

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

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

ChrisQ <meru@devnull.com> wrote:
> 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.

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

John Devereux <john@devereux.me.uk> wrote:
> 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???.

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

Anders.Montonen@kapsi.spam.stop.fi.invalid writes:

> John Devereux <john@devereux.me.uk> wrote:
>> 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???.
>
> 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

Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:

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

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