Cross compiling for Cortex A9

Michael Jones mike at proclivis.com
Sat Aug 2 05:04:10 UTC 2014 

Karel,

I was able to get GHC to compile by rebuilding the gcc cross compiler using —with-arch= and —with-tune=

However, it is not a satisfactory solution, because if a gcc toolchain uses multilibs, adding those options does not make sense. In the case of the Yocto toolchain, it does not use multilibs, so I can get away with it.

I’ll test the compiler tomorrow and see how things go.

Here is the GHC info after building:

 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","arm-poky-linux-gnueabi-gcc")
 ,("C compiler flags"," -fno-stack-protector")
 ,("C compiler link flags","")
 ,("Haskell CPP command","arm-poky-linux-gnueabi-gcc")
 ,("Haskell CPP flags","-E -undef -traditional ")
 ,("ld command","/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld")
 ,("ld flags","")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","YES")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("ar command","/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ar")
 ,("ar flags","q")
 ,("ar supports at file","YES")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("target os","OSLinux")
 ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}")
 ,("target word size","4")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","False")
 ,("Unregisterised","NO")
 ,("LLVM llc command","/usr/bin/llc")
 ,("LLVM opt command","/usr/bin/opt")
 ,("Project version","7.8.3")
 ,("Booter version","7.6.3")
 ,("Stage","1")
 ,("Build platform","x86_64-unknown-linux")
 ,("Host platform","x86_64-unknown-linux")
 ,("Target platform","arm-poky-linux")
 ,("Have interpreter","YES")
 ,("Object splitting supported","NO")
 ,("Have native code generator","NO")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l  ")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","NO")
 ,("Leading underscore","NO")
 ,("Debug on","False")
 ,("LibDir","/home/mike/ghc-7.8.3/inplace/lib")
 ,("Global Package DB","/home/mike/ghc-7.8.3/inplace/lib/package.conf.d")
 ]



On Aug 1, 2014, at 8:02 PM, Michael Jones <mike at proclivis.com> wrote:

> Karel,
> 
> I think I proved that make dies early if CFLAGS has these options. The local gcc does not support ARM related flags.
> 
> I am trying to build the tool chain with —with-arch= and —with-tune== so that it defaults to my target. This will bypass any GHC build issues.
> 
> Mike
> 
> On Aug 1, 2014, at 3:23 PM, Michael Jones <mike at proclivis.com> wrote:
> 
>> Karel,
>> 
>> On CFLAGS..
>> 
>> When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler?
>> 
>> Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen.
>> 
>> Mike
>> 
>> Sent from my iPad
>> 
>>> On Aug 1, 2014, at 3:19 AM, Karel Gardas <karel.gardas at centrum.cz> wrote:
>>> 
>>> 
>>> OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you?
>>> 
>>> Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS.
>>> 
>>> Karel
>>> 
>>>> On 07/25/14 06:00 AM, Michael Jones wrote:
>>>> 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
>>>> <mailto: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
>>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

More information about the Glasgow-haskell-users mailing list