Cross compiling for Cortex A9

[Michael Jones]

I have some progress, and a problem. First, note I am using the 7.8.3 tar ball, for this discussion here.

If you read through, you will see a request for help at the end. It looks like the cross compilation is trying to build stage2 when it shouldn’t.

In order to get the resulting stage1 cross compiler to have:

 ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}")

I hacked this:

AC_DEFUN([GET_ARM_ISA],
[
    changequote(, )dnl
    ARM_ISA=ARMv7
    ARM_ISA_EXT="[VFPv3,NEON]"
    changequote([, ])dnl
    [ARM_ABI="HARD"]
])

Now, my gcc cross compiler does not default to ARMv7. To compile for my Cortex A, I add these options:

-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9

So I need to make sure that when building the libraries with stage1, it passes the correct options. To do that:

AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS],
[
    AC_MSG_CHECKING([Setting up $2, $3, $4 and $5])
…
    arm-poky-*)
	$2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9"
	;;


Which results in a stage1 compiler with:

 ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector”)

As the build proceeds, all calls to stage1 are completing. Then, the build gets to this point:

"inplace/bin/mkdirhier" compiler/stage2/build//.
"rm" -f compiler/stage2/build/Config.hs  
Creating compiler/stage2/build/Config.hs ... 
done.

And I assume this means it is trying to build stage2. Correct me if I am wrong.

Eventually I get a build failure like this:

gcc -E  -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES  -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector   -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2   -DGHCI  -I'/home/mike/ghc-7.8.3/libraries/process/include' -I'/home/mike/ghc-7.8.3/libraries/directory/include' -I'/home/mike/ghc-7.8.3/libraries/unix/include' -I'/home/mike/ghc-7.8.3/libraries/time/include' -I'/home/mike/ghc-7.8.3/libraries/containers/include' -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' -I'/home/mike/ghc-7.8.3/libraries/base/include' -I'/home/mike/ghc-7.8.3/rts/dist/build' -I'/home/mike/ghc-7.8.3/includes' -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header'        -MM -x c compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit
gcc: error: unrecognized command line option ‘-mthumb-interwork’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’
gcc: error: unrecognized command line option ‘-mfpu=neon’
make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1
make: *** [all] Error 2

It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler.

Now, in build.mk I have:

BuildFlavour  = quick-cross

Which is supposed to prevent stage2 compilation.

Something is wrong. Either I need to stop stage2 compilation, if that is what this is really doing, or prevent gcc from using the extra arguments. But I see no reason to run gcc. Seems like that would only be used at stage0 if at all.

Mike

On Jul 14, 2014, at 10:12 AM, Karel Gardas <karel.gardas at centrum.cz> wrote:

> On 07/14/14 04:58 PM, Michael Jones wrote:
>> Karel,
>> 
>> Thanks. This helps.
>> 
>> If I understand, you have Linux running on a Panda, and on that Panda
>> system you have gcc, and you compile GHC on the Panda itself, rather
>> than build a cross compiler. I can see the advantage of building this
>> way.
> 
> Correct!
> 
>> As far as cross compilers, I have a reason for trying to build a
>> cross compiler, other than the ability to keep the image of the
>> target small. That is, eventually, I want to be able to compile for
>> an RTOS and/or bare iron system. I decided that learning to cross
>> compile for Linux first would be a good approach. Learn the build
>> system on something known to work. So I probably will not give up on
>> that.
> 
> That is right, in future I'd also like to give a try to port GHC to some free RTOS and for this I'd need to use cross-compiling anyway, so I'll be on the same boat...
> 
>> I got a book on Autoconfig. I’ll just have to dig a level deeper into
>> the whole build system. Mainly it means learning the M4 system. I
>> have never used it.
>> 
>> Below are the defines from the command you suggested. Thanks for
>> that, got me over an ignorance hump. At least this define,
>> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study
>> the macros until I figure out what controls the gcc options passed to
>> the gcc cross compiler. I guess my question is what actually controls
>> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt =
>> [VFPv3,NEON], armABI = HARD}”)?
>> 
>> Are these controlled by the defines below, or are they controlled by
>> passing gcc arguments to the gcc compiler when the Haskell compiler
>> calls gcc?
> 
> Basically speaking all those are controlled by platform gcc. That means if you pass the right option to your cross-compiling gcc you should also get the same result, so for example if you use:
> 
> gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16
> 
> you should get the same settings like me.
> 
> But anyway, please note that ABI you set to your cross-compiler *have to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-)
> 
> Cheers,
> Karel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140724/1f3e0f48/attachment.html>