[yocto] Cross compiler which runs on the target architecture.

[Nathan Rossi]

On Tue, Dec 23, 2014 at 12:53 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> Hi,
>
> On Sat, 2014-12-20 at 14:43 +0000, Peter Saunderson wrote:
>> I have seen a brief IRC chat
>> (https://www.yoctoproject.org/irc/%23yocto.2013-09-23.log.html talking
>> about https://github.com/nathanrossi/meta-parallella) about this
>> question but nothing much else so this is an attempt to get more public
>> feedback on this request.

That was me, as you might have noticed I ended up for now just using a
pre-built toolchain that was copied into the system image with a
recipe. This works but its not ideal.

There have been a few threads recently regarding similar functionality desires:
 * https://lists.yoctoproject.org/pipermail/yocto/2014-December/022751.html
 * https://lists.yoctoproject.org/pipermail/yocto/2014-December/022653.html
(this one is more about multi-machine builds, but still relevant)

>>
>> I am trying to build a cross compiler that runs on the target processor
>> and a cross compiler that runs on the host processor so that I can build
>> code for a third processor (Epiphany).  If you want examples of the
>> traditional way to build this compiler look at
>> https://github.com/adapteva/epiphany-sdk epiphany-gcc epiphany-newlib
>> epiphany-binutils... The end result would be a set of recipes that run
>> on a pc build machine that build both arm code for the interim target
>> and epiphany code for the final target and provides an SDK for the pc
>> that enables you to cross compile for both arm and epiphany.

I have been interested in this myself for the epiphany case as well as
a few additional cases (from a personal interest as well as for
Xilinx/meta-xilinx):
 * epiphany native, nativesdk and target cross compilers
 * baremetal toolchain (using newlib)
 * canadian-cross arch baremetal (e.g. arm host building for
microblaze baremetal)
 * and also (canadian-)cross arch linux

>>
>> As I am just starting to look at this I would like to know what size of
>> task I am up against!  My initial efforts based on review of
>> poky/meta/recipes-devtools/binutils etc seem to suggest that I have to
>> modify at least ${HOST_PREFIX}, ${TARGET_PREFIX}, ${TARGET_ARCH} etc for
>> my epiphany-??? recipes so that the I can install the compiler in a
>> suitable location with a suitable prefix, the IRC chat indicates that
>> there are more things to consider also.
>>
>> The question I have is about how easy it will be to use existing recipes
>> for existing compiler / binutils etc... or is this likely to end up as a
>> completely new set of recipes from the ground up because the existing
>> recipes cant cope with building cross / cross compilers where there are
>> three processors to consider (host (intel based pc), interim target
>> (arm) and final target (epiphany)), or at least a lot of changes in the
>> existing recipes to cope with something like TARGET_TARGET_ARCH =
>> ${TARGET_ARCH}_${FINAL_TARGET_ARCH}??
>
> Funnily enough I've a similar need to do something like this for a
> personal project but targeting AVR.
>
> Certainly OE has the power and capability to do something like this, I'm
> not sure its straightforward though, at least generically, and I say
> that as one of the people with pretty intimate knowledge of the
> toolchain recipes.
>
> The easy parts are creating recipes for binutils and gcc to run on the
> target, targeting a third arch. This is like cross-canadian but built to
> run on MACHINE instead of SDKMACHINE and taretting a new arch (probably
> 'target-cross-canadian'). The massively harder part is the libc for gcc
> to build against and any other libs for the system.
>
> The issue is that bitbake.conf locks the choice of MACHINE early in the
> configuration stage. We added SDKMACHINE as a way of letting us build
> SDKs and we have multilib and BBCLASSEXTEND but these all only target a
> single arch.
>
> Part of me tries to ensure whatever solution we come up with can scale.
> This means I'd like my arm target to be able to build compilers
> targetting x86, mips and ppc as well as arm, all in one build. The
> question then comes to libc and whether you'd rebuild libc each time,
> whether you'd reuse the same libc package as a standard build or whether
> you'd have a special version of the libc for the 'target-cross-canadian'
> toolchain.

There is definitely quite a bit of madness in getting oe to build
additional toolchains even for the same architecture, let alone
different architectures. ;)

I have been playing around with getting a baremetal toolchain to build
alongside the linux one, it seemed like a good place to start before
diving into additional arch, cross-canadian builds. With the
BBCLASSEXTEND stuff, I have gotten a fair way into the process of
having a class providing overrides to the gcc-*/binutils-* recipes to
allow for bitbake to build a secondary baremetal (with newlib)
toolchain alongside the default machine/target toolchain. There are
however changes that I needed to make to the recipes to make them more
friendly within the tmp/sysroot/* structure during the intial and main
pass builds of the toolchain, there is also the whole issue of
dependency naming and virtual/* providers which works reasonably due
to the virtual/${TARGET_PREFIX} being used.

For now I have been overriding TARGET_OS/TCLIBC/etc with the use of
_class-* overrides in local.conf. However the multilib setup relies on
the use of DEFAULTTUNE for the setup of additional configurations,
with some reworking of the tune-*.inc it would be possible to include
multiple architecture types and rely on the DEFAULTTUNE to setup
TUNE_*/TARGET_* with class overrides.

It does seem like it would possible to handle all the cases I am after
(at least) using BBCLASSEXTEND and some dynamic classes in the same
way multilib works. I imagine support for heterogeneous builds could
be a real good selling point for yocto/oe, especially with the large
volume of modern SoC's having some form of mixed architectures these
days :).

Regards,
Nathan

>
> Stepping back from that craziness, I suspect some specialist recipes for
> avr/epiphany would probably be easiest right now, albeit less
> satisfying.
>
> Cheers,
>
> Richard
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto