Cannot build GCC for Cortex-M0

Kai Ruottu kai.ruottu@wippies.com
Thu Sep 2 13:41:00 GMT 2010


2.9.2010 12:27, Andriy Sukhynyuk kirjoitti:

> When I try to compile C-source file with Code Red LPCXpresso which is shipped
> with GCC 4.3.3 with -mcpu=cortex-m0 but without -mthumb
>
> arm-none-eabi-gcc  -I"YYYY" -O0 -g3 -Wall -c -fmessage-length=0 -fno-builtin
> -ffunction-sections -mcpu=cortex-m0  -MMD -MP -MF"src/XXXX.d" -MT"src/XXXX.d"
> -o"src/XXXX.o" "../src/XXXX.c"
>
> I get the message:
>
> ../src/XXXX.c:1: error: target CPU does not support ARM mode
> make: *** [src/XXXX.o] Error 1

This error seems to claim there being something wrong in the
'../src/XXXX.c', line #1, on the very first source line. What
there really is?

Generally I'm not familiar with those dependency outputs but
they shouldn't have any influence to this.

If the line #1 looks ok, then some kind of step-by-step approach
could be tried via the '-save-temps' :

-save-temps
    Store the usual “temporary” intermediate files permanently;
    place them in the current directory and name them based on
    the source file. Thus, compiling ‘foo.c’ with ‘-c -save-temps’
    would produce files ‘foo.i’ and ‘foo.s’, as well as ‘foo.o’.

I think the earlier intermediate files should be generated although
the compile would stop later in the next stage.

> Returning back to building toolchain with multilib enabled and default mode
> --with-mode=arm, I made the following changes to
> \gcc-4.5.0\gcc\config\arm\t-arm-elf file
>
>
> +MULTILIB_OPTIONS      += march=armv6-m mthumb
> +MULTILIB_DIRNAMES     += thumb\/armv6-m
>
> +MULTILIB_EXCEPTIONS   += *marm*/*march=armv6-m*
>
> +MULTILIB_OPTIONS    += mno-thumb-interwork/mthumb-interwork
> +MULTILIB_DIRNAMES   += normal interwork
> +MULTILIB_EXCEPTIONS += *mthumb-interwork*/*march=armv6-m*
>
> I would like to think that  *marm*/*march=armv6-m* forbids building ARM library
> when -marmv6-m is present but it does not!

These don't look sane, the original settings are :

MULTILIB_OPTIONS     = marm/mthumb
MULTILIB_DIRNAMES    = arm thumb
MULTILIB_EXCEPTIONS  =
MULTILIB_MATCHES     =

Saying that code produced with '-marm' would be put to 'lib/arm' and
code produced with '-mthumb' to 'lib/thumb'. Another of these can be
the default and so being put in 'lib'. The '--with-mode=thumb' would
change the default '-marm' to '-mthumb'.

Instead of adding rows you maybe should comment away the later :

MULTILIB_OPTIONS       += mfloat-abi=hard
MULTILIB_DIRNAMES      += fpu
MULTILIB_EXCEPTIONS    += *mthumb/*mfloat-abi=hard*

with '#' first in the line. And uncomment the interwork settings :

# MULTILIB_OPTIONS    += mno-thumb-interwork/mthumb-interwork
# MULTILIB_DIRNAMES   += normal interwork

If you use '--with-arch=armv6-m' instead of '--with-cpu=cortex-m0',
in the GCC configure the '-mthumb' (default) and '-marm' (optional
multilib) codes should be for the 'armv6-m' variation.

If the Cortex-M0 CPU doesn't understand any '-marm' code, where on
earth the optional '-marm' code would be run?

Maybe the easy way could be to put the '-mcpu=cortex-m0' specific libs
into a 'lib/cortex-m0' subdir and add multilib definitions for this
if the bare default '-march=armv6-m -mthumb' doesn't produce the same
codes as '-mcpu=cortex-m0'.

I will try this myself, first I only removed the '--disable-multilib'
and '--disable-interwork', didn't edit the multilib defs, so I got :

/home/src/gcc-4.5.1/build/./gcc/xgcc -B/home/src/gcc-4.5.1/build/./gcc/ 
-B/usr/local/arm-eabi/bin/ -B/usr/local/arm-eabi/lib/ -isystem 
/usr/local/arm-eabi/include -isystem /usr/local/arm-eabi/sys-include 
-g -Os -mfloat-abi=hard -O2  -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE 
  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include 
-fno-inline -Wno-missing-prototypes -g  -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../../.././gcc 
-I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc 
-I../../../../libgcc/../include  -DHAVE_CC_TLS  -o _powisf2.o -MT 
_powisf2.o -MD -MP -MF _powisf2.dep -DL_powisf2 -c 
../../../../libgcc/../gcc/libgcc2.c \

../../../../libgcc/../gcc/libgcc2.c: In function '__powisf2':
../../../../libgcc/../gcc/libgcc2.c:1739:1: error: insn does not satisfy 
its constraints:
(insn 112 8 3 2 ../../../../libgcc/../gcc/libgcc2.c:1729 (set (reg/v:SF 
6 r6 [orig:141 x ] [141])
         (reg:SF 63 s0 [ x ])) 182 {*thumb1_movsf_insn} (nil))
../../../../libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in 
reload_cse_simplify_operands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [_powisf2.o] Virhe 1
make[4]: Poistutaan hakemistosta 
"/home/src/gcc-4.5.1/build/arm-eabi/fpu/libgcc"

It had already succeeded with a libgcc.a in 'arm-eabi/thumb/libgcc'...
Probably it was a duplicate for the becoming 'arm-eabi/libgcc/libgcc.a'.
Let's comment the extra multilib defs away and see where the smoke rises
then...



More information about the Gcc-help mailing list