[OE-core] [PATCH] Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe"

[alexandru.sardan at freescale.com]

Hi,

e500v1/v2 uses SPE to handle floating point operations
using general purpose regs.
So using the non-SPE compiler with SPE libraries won't work.
However the soft-fp libraries are compatible with the e500 
ABI (with a considerable performance penalty).

From what I can see, eglibc is built with SPE. So GCC should 
be built also for SPE (target powerpc-poky-linux-gnuspe).

Kind regards,
Alex

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> David Nyström
> Sent: Tuesday, January 14, 2014 3:24 PM
> To: Luo Zhenhua-B19537
> Cc: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> linux verses linux-gnuspe"
> 
> On 2014-01-13 13:41, Richard Purdie wrote:
> > On Mon, 2014-01-13 at 13:37 +0100, David Nyström wrote:
> >> Just to clarify bug 5354:
> >> If I understand the bug correctly, this would arise when first
> building
> >> the nativesdk tarball on a MACHINE with ABI linux,
> >> and then building the nativesdk for another MACHINE(with the same the
> >> same TUNE) after altering ABIEXTENSION to linux-gnuspe ?
> >>
> >> If I understand bug 5354 correctly, perhaps the tmp/sdk/tarball.here
> >> can be ABI specific ?
> >
> > The idea behind the changes to cross-canadian were to have just a
> single
> > gcc/binutils which generated all of the appropriate targets for a given
> > architecture.
> >
> > I understood this to be possible but it looks like we may need to tweak
> > things a bit.
> >
> >> i.e. a generic rule that all nativesdk builds are invalidated if the
> >> ABI changes. I guess that would mean:
> >> cross-canadian.bbclass: TARGET_ARCH[vardeps] += "ABIEXTENSION"
> >> + Adding ABIEXTENSION to the nativesdk tarball name.
> >>
> >> PPC '=mabi=spe' seems to be one-way compatible,  I could not get the
> >> non-SPE configured compiler
> >> to work with the SPE sysroot.
> >> Another possible solution would be to always configure the compiler to
> >> SPE, and use compile time flags in the
> >> environment file to do the selects. + symlinks for the compiler paths.
> >
> > Can we configure the compiler to include SPE support without changing
> > the paths/OS string?
> 
> Possibly, but I don't know enough about SPE to be sure.
> Perhaps Zhenhua can add a few cents here.
> 
> Short summary of problem:
> All SPE enabled MACHINES, (e500 and e500v2) have broken nativesdk
> compilers in dora and master.
> 
> Any suggestions on above statements ?
> 
> >
> >> However, even if we fix it this way for powerpc, we will still have
> >> this issue with thumb f.ex.
> >
> > Keep in mind the target sysroot still varies for each different target.
> > The thing we're trying to keep in common is the gcc/bintuils and only
> > have one copy for each target architecture. Is that possible in this
> > case if we somehow enable SPE support in gcc-cross-canadian?
> 
> Yes, target sysroot varies. The nativesdk sysroot containing the
> compiler is the same as long as TUNE_ARCH and SDKMACHINE is the same.
> Two ARMv8 targets built in sequence on the same host, where one is
> Thumb2 and the other is EABI ?, they will share nativesdk compiler no ?
> 
> The -native compiler runs from the -native sysroot, which has an ABI
> postfix, so no problem there I assume.
> 
> >
> > Cheers,
> >
> > Richard
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core