New Sourcery G++ released

[phrosty]

I just got this via their announce list. It looks like this will be very beneficial for cross-compiling for the Pandora!

CodeSourcery is pleased to announce the availability of the 2008q1
Sourcery G++ Lite Edition release for ARM processors. This is
available for download from:

http://www.codesourcery.com/gnu_toolchains/arm

New features in this release include:

* GCC has been upgraded from GCC 4.2.3 to GCC 4.3.2. This upgrade
provides improved optimization, as well as a number of new features and
quality improvements. Other components, including GDB, Binutils, and
GLIBC have also been upgraded.

* Improved optimization for Cortex-A8 and other ARM CPUs.

* Improved support for NEON and, in particular, auto-vectorization using
NEON.

* Half-precision (16-bit) floating-point support for Cortex-A9 CPUs.

Enjoy!

 

[streak]

finally, yeah!

 

[lardman]

Just as long as we get a list of patches so we can build our own version of the toolchain (and even improve it!) using OE....

 

[phrosty]

Just as long as we get a list of patches so we can build our own version of the toolchain (and even improve it!) using OE....

We would just use vanilla GCC on the Pandora - unless I'm missing something, Sourcery is just a cross-compiler.

 

[Etinin]

Why not use a vanilla gcc cross-compiler though? We could always make a script to make it easy to compile a cross-compiler.
I don't think we should use a version compiled by a proprietary company as the default one in the (perhaps un)official SDK.
You even need to strip that version of some proprietary ARM debugging sprites before distributing it.

 

[mkinzler]

But they also provide the source, so you can compile it on your own.
Because of the optimation in it, it should be preferred

 

[phrosty]

Why not use a vanilla gcc cross-compiler though?

I could be mistaken, but I believe Sourcery *is* vanilla - it's just an easy binary to use.

 

[Etinin]

Well, Sourcery G++ links against Newlib instead of standard glibc, something that might create some trouble with programs using GNU features, I think we should use standard GNU stuff as much as possible to avoid problems. Pandora is not some crappy device with a crappy processor to justify the use of Newlib.

 

[Bronek]

Well, Sourcery G++ links against Newlib instead of standard glibc, something that might create some trouble with programs using GNU features, I think we should use standard GNU stuff as much as possible to avoid problems. Pandora is not some crappy device with a crappy processor to justify the use of Newlib.

I just found about codesourcery and downloaded getting-started.pdf and I know very little about it. However, I found the following in chapter 3.2.6

It is possible to create object files using Sourcery G++ for ARM EABI that are link-compatible with the GNU C library provided with Sourcery G++ for ARM GNU/Linux as well as with the Newlib C library provided with the ARM EABI toolchain.

Thus it seems like it should be possible to use it with standard GNU C library?

 

[Etinin]

Sorry folks. Well, actually, I was wrong, I looked at the wrong release of CodeSourcery, the one for Linux uses glibc. However, I'm still unconvinced of the need to use a gcc branded by a proprietary vendor (like when typing gcc --version). It's not so hard to build a vanilla GNU toolchain.

 

[slygamer]

I've never found anything Linux-based to be easy to build, especially for Win32, so if someone makes a pre-built and tested native Win32 version available that does not depend on Cygwin or MinGW or any other *nix-alike shell, I'll gladly use it. Good job CodeSourcery on doing so.

 

[fordp]

I know what you are saying about using a Stock GCC. Codesourcery however is worth consideration.

They are very close to ARM and I believe actually wrote the ARM7 support in GCC including the Thumb2 support.

I have been following this as I am an Embedded software guy and I am considering using a Cortex M3 in my next project.

This brings me on to the question of which instruction set will be use on Pandora programming ???

Will it be ARM32 or Thumb2 or a mixture ???

Well there goes my first post

 

[notaz]

Unfortunately both of their releases from 2007q3 are broken (produce bad code), even the latest one

 

[fordp]

I have used an earlier version of Sourcery G++ on a Luminary Micro Cortex M3 part. I only used it for a bit of hacking but I did get it working for me.

That was a few months ago.

It was not totally painless and it being the "Lite" version of paid for package did prove problematic.

I got round that however and was just left with bugs in the code base I was Hacking, Doh!

I am sorry to hear that Sourcery G++ has problems.

This does not bode well for optimsed support for the ARM7 generation Cortex chip.

Do you have any links highlighting the problems ????

 

[Bronek]

Unfortunately both of their releases from 2007q3 are broken (produce bad code), even the latest one

I actually find it surprising, given that codesourcery is considered THE toolchain used to build Pandora, and given that it officially supports Cortex-A8. I would also guess that THE glibc supplied with the Pandora OS is the one from codesourcery, and this is perfectly fine with me. Although I found no word of confirmation from official source.

 

[cosam]

I would also guess that THE glibc supplied with the Pandora OS is the one from codesourcery, and this is perfectly fine with me. Although I found no word of confirmation from official source.

I was wondering about this too. It could just as likely be the glibc from Angstrom, or something built specifically for the Pandora.

 

[notaz]

http://hardwarebug.org/2008/10/11/codes ... 08q3-fail/

Somebody compiled u-boot (which doesn't use NEON) and it was broken too, so we'll just stick to 2007q3.

 

[Bronek]

Oh, what a shame. I was hoping I would get it off the shelf working well with the current version of GCC. Well, I hope I will be able to rebuild the binaries myself when they fix the bug.

 

[maciek_urbanski]

...or we can disable NEON vectorization (using --fno-tree-vectorize) and vectorize manually using NEON intrinsics.

Because even working GCC vectorization for NEON is far from optimal - see this(link) thread.