This is the mail archive of the
mailing list for the GCC project.
Re: Bare metal ARM Cross compiler - aeabi auto-generated functions for cortex-m0 use wrong instruction set
On 4/12/2012, at 3:54 Maxim Kuvyrkov wrote:
> > Hi!
> > I'm trying to get the cross-toolchain for cortex-m0 working. The target is arm-none-eabi.
> > The gcc has no problem compiling my code using allowed instructions only. As long as I do not try to use / or % my code runs as expected.
> > When I try to divide, GCC uses and appends ARM runtime ABI functions (which is correct, since m0 has no hardware division op).
> > The problem is that included functions (in particular: __aeabi_idiv) use instructions that are _not_ part of the cortex-m0 instructions set (like lsleq, movne, rsbmi).
> > I compile and link the code with '-mcpu=cortex-m0 -mthumb' flags.
> > What I want to is to force gcc to include the ARM runtime ABI functions that work with cortex-m0.
> > How can I get it working? Am I missing something? Is it anyhow possible?
> How libgcc (and other GCC libraries) are compiled is defined by multilib flags. It appears that the default multilib for the compiler that you built is not "-mcpu=cortex-m0" (probably, it's something ARMv4-ish).
> For a quick fix try adding --with-arch=cortex-m0 to GCC configure line.
I'm going to check if this would help. The workaround would however mean that to switch from Cortex-M0 to Cortex-M4 and vice-versa I'd either need two separate gcc builds or I could relay on the fact that m0 instruction set is subset of m4. Both nasty...
On 3/12/2012, at 1:00 Chris Johns wrote:
> As far as I can tell you are not missing anything. I raised the issue not long ago ...
> Maybe this patch helps. It helped me with gcc 4.7.2 and the Cortex-3M I was using ...
(Sorry no to respond in a separate mail with reference, but probably built-in spam filter discarded the massage :?)
Thanks for this post, now I know what the problem really is about. Sadly the patch you provide does not take under account cortex-m0. If I have time, I'll try to dig into it.
Currently I'm linking my code with an external aeabi for cortex-m0 taken from:
This works fine as a workaround and is at least portable (i.e. I can send the code to a friend using unpatched gcc).
btw, as Chris noticed, not only aeabi functions use wrong instruction set, all libs added by the linker are unmatched, e.g. stdlib.