This is the mail archive of the
mailing list for the eCos project.
Re: eCos arm-eabi GNU tools - test release 4.6.3-20120623
- From: David Fernandez <david dot fernandez dot work at googlemail dot com>
- To: John Dallaway <john at dallaway dot org dot uk>
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 26 Jun 2012 22:50:32 +0100
- Subject: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.3-20120623
- References: <4FE9982C.firstname.lastname@example.org>
On 26/06/12 12:08, John Dallaway wrote:
> I have generated a new test release of the GNU tools for ARM targets.
> The new test release avoids an issue with the length of GDB 'g' packet
> replies when working with Cortex-M targets that was seen with the
> previous test release. GDB is now built from 7.4.1 sources with an
> M-profile patch based on current GDB sources.
Could you provide a link to the patch tarball? I usually build the
tool-chain, and like to try that.
> GCC 4.6.3 is now built
> with additional multilib setup for Cortex-A9 processors.
Now that you mention multilib, I noticed that, when building gcc for
arm-eabi, cpus like cortex-m3 require you (perhaps that is my mistake)
to build it --with-cpu=cortex-m3 --with-mode=thumb (at least), so that
newlib's crt0.S gets compiled in thumb-2 mode, so that the right code is
generated when using the options -mcpu=cortex-m3 -mthumb.
I wonder why crt0.S is not compiled multiple times with all the options
required for the cpus and modes supported by the arm-eabi target... I
thought that multilib was to ensure that (although I may be wrong about
Do you know something about this? The crossgcc list seems to be very
quiet, and nobody there seems to be willing to give an answer on that.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss