Patchwork Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe"

login
register
mail settings
Submitter David Nyström
Date Jan. 10, 2014, 2:48 p.m.
Message ID <1389365286-4830-1-git-send-email-david.nystrom@enea.com>
Download mbox | patch
Permalink /patch/64533/
State New
Headers show

Comments

David Nyström - Jan. 10, 2014, 2:48 p.m.
The reverted commit seems to introduce some problems for the toolchain tarball
for powerpc.
I see this both in master and on dora.

1. Looks like the relocation scripts fails for environments:

~/tests/poky [master]
$ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep "#"
export SDKTARGETSYSROOT=##SDKTARGETSYSROOT##

~/tests/poky [master]
$ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux-gnuspe | grep "#"

2. nativeSDK gnuspe compiler does not allow -mabi=spe
ABIEXTENSION is zeroed both for linux-gnuspe and linux

3. Compiler can't create executables.
I think this is due to libgcc_s.so from the SDK target sysroot is in mabi=spe.

4. -mspe is included in CC var for both linux and gnuspe.
cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep mabi
export CC="powerpc-oel-linux-gcc  -m32 -mcpu=8548 -mabi=spe -mspe ....
export CXX="powerpc-oel-linux-g++  -m32 -mcpu=8548 -mabi=spe -mspe ....
export CPP="powerpc-oel-linux-gcc -E  -m32 -mcpu=8548 -mabi=spe -mspe ....

With the commit reverted, I can successfully build target code with the canadian compiler 
from the SDK tarball. Only the gnuspe environment file is generated.

This reverts commit 11d9127ac57514394f8297f9fdfc7b31e163fcb8.
---
 meta/classes/cross-canadian.bbclass                | 31 ----------------------
 .../binutils/binutils-cross-canadian.inc           |  2 --
 meta/recipes-devtools/gcc/gcc-cross-canadian.inc   |  5 +---
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc   |  1 -
 4 files changed, 1 insertion(+), 38 deletions(-)
Richard Purdie - Jan. 10, 2014, 3:15 p.m.
On Fri, 2014-01-10 at 15:48 +0100, David Nyström wrote:
> The reverted commit seems to introduce some problems for the toolchain tarball
> for powerpc.
> I see this both in master and on dora.
> 
> 1. Looks like the relocation scripts fails for environments:
> 
> ~/tests/poky [master]
> $ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep "#"
> export SDKTARGETSYSROOT=##SDKTARGETSYSROOT##
> 
> ~/tests/poky [master]
> $ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux-gnuspe | grep "#"
> 
> 2. nativeSDK gnuspe compiler does not allow -mabi=spe
> ABIEXTENSION is zeroed both for linux-gnuspe and linux
> 
> 3. Compiler can't create executables.
> I think this is due to libgcc_s.so from the SDK target sysroot is in mabi=spe.
> 
> 4. -mspe is included in CC var for both linux and gnuspe.
> cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep mabi
> export CC="powerpc-oel-linux-gcc  -m32 -mcpu=8548 -mabi=spe -mspe ....
> export CXX="powerpc-oel-linux-g++  -m32 -mcpu=8548 -mabi=spe -mspe ....
> export CPP="powerpc-oel-linux-gcc -E  -m32 -mcpu=8548 -mabi=spe -mspe ....
> 
> With the commit reverted, I can successfully build target code with the canadian compiler 
> from the SDK tarball. Only the gnuspe environment file is generated.

Ok, so how do you propose we fix the issues the patch was added to
address?

Cheers,

Richard
David Nyström - Jan. 13, 2014, 12:37 p.m.
On fre 10 jan 2014 16:15:08, Richard Purdie wrote:
> On Fri, 2014-01-10 at 15:48 +0100, David Nyström wrote:
>> The reverted commit seems to introduce some problems for the toolchain tarball
>> for powerpc.
>> I see this both in master and on dora.
>>
>> 1. Looks like the relocation scripts fails for environments:
>>
>> ~/tests/poky [master]
>> $ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep "#"
>> export SDKTARGETSYSROOT=##SDKTARGETSYSROOT##
>>
>> ~/tests/poky [master]
>> $ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux-gnuspe | grep "#"
>>
>> 2. nativeSDK gnuspe compiler does not allow -mabi=spe
>> ABIEXTENSION is zeroed both for linux-gnuspe and linux
>>
>> 3. Compiler can't create executables.
>> I think this is due to libgcc_s.so from the SDK target sysroot is in mabi=spe.
>>
>> 4. -mspe is included in CC var for both linux and gnuspe.
>> cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep mabi
>> export CC="powerpc-oel-linux-gcc  -m32 -mcpu=8548 -mabi=spe -mspe ....
>> export CXX="powerpc-oel-linux-g++  -m32 -mcpu=8548 -mabi=spe -mspe ....
>> export CPP="powerpc-oel-linux-gcc -E  -m32 -mcpu=8548 -mabi=spe -mspe ....
>>
>> With the commit reverted, I can successfully build target code with the canadian compiler
>> from the SDK tarball. Only the gnuspe environment file is generated.
>
> Ok, so how do you propose we fix the issues the patch was added to
> address?
>
> Cheers,
>
> Richard
>

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 ?
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.
However, even if we fix it this way for powerpc, we will still have 
this issue with thumb f.ex.

It would be good if the Freescale folks could chime in here.

Br,
David
Richard Purdie - Jan. 13, 2014, 12:41 p.m.
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?

> 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?

Cheers,

Richard
David Nyström - Jan. 14, 2014, 1:23 p.m.
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
>
Alexandru-Cezar Sardan - Jan. 17, 2014, 2:43 p.m.
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@lists.openembedded.org

> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of

> David Nyström

> Sent: Tuesday, January 14, 2014 3:24 PM

> To: Luo Zhenhua-B19537

> Cc: openembedded-core@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@lists.openembedded.org

> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Richard Purdie - Jan. 18, 2014, 11:20 a.m.
On Fri, 2014-01-17 at 14:43 +0000, alexandru.sardan@freescale.com wrote:
> 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).

The key question is this:

Can one gcc binary generate code for both non-SPE and SPE targets,
assuming its pointed at an appropriate sysroot containing appropriate
libraries?

If we can have one such binary, how do we configure it? If we can't, we
need to redo the way gcc-cross-canadian is working on powerpc.

The change there was to have one gcc for each different target
architecture rather than each "tune" since that was horribly
inefficient.

Cheers,

Richard
Alexandru-Cezar Sardan - Jan. 21, 2014, 5:39 p.m.
Hi,

Yes, the gcc configured for SPE (--target=powerpc-fsl_networking-linux-gnuspe)
can generate both SPE and non-SPE code provided that software 
floating point is used.

There are a couple of parameters (-mabi=no-spe -mno-spe) that will turn
off SPE vector instructions generation. If the code contains floating
point arithmethic -msoft-float needs to be used as well. This means that
the GCC multilib setup has to be configured to include soft float and
build coresponding version of libgcc and target fragments.
But why would we want to generate code without SPE for e500v1/v2? 
Soft-float comes with a major performance penalty.

Maybe I didn't understand correctly what kind of toolchain you want to
be built in the end. Do you want to have a single GCC that builds all
powerpc targets (e500v2, e5500, e6500 etc) and a separate sysroot for each 
target? 
This may be problematic since, for example, the compiler that can generate 
SPE (for e500v2) can't generate altivec instructions (for e6500).

Kind regards,
Alex


> -----Original Message-----

> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]

> Sent: Saturday, January 18, 2014 1:20 PM

> To: Sardan Alexandru Cezar-B41700

> Cc: David Nyström; Luo Zhenhua-B19537; openembedded-

> core@lists.openembedded.org

> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc

> linux verses linux-gnuspe"

> 

> On Fri, 2014-01-17 at 14:43 +0000, alexandru.sardan@freescale.com wrote:

> > 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).

> 

> The key question is this:

> 

> Can one gcc binary generate code for both non-SPE and SPE targets,

> assuming its pointed at an appropriate sysroot containing appropriate

> libraries?

> 

> If we can have one such binary, how do we configure it? If we can't, we

> need to redo the way gcc-cross-canadian is working on powerpc.

> 

> The change there was to have one gcc for each different target

> architecture rather than each "tune" since that was horribly

> inefficient.

> 

> Cheers,

> 

> Richard

> 

> 

> 

>
Richard Purdie - Jan. 21, 2014, 5:43 p.m.
On Tue, 2014-01-21 at 17:39 +0000, alexandru.sardan@freescale.com wrote:
> Yes, the gcc configured for SPE (--target=powerpc-fsl_networking-linux-gnuspe)
> can generate both SPE and non-SPE code provided that software 
> floating point is used.
> 
> There are a couple of parameters (-mabi=no-spe -mno-spe) that will turn
> off SPE vector instructions generation. If the code contains floating
> point arithmethic -msoft-float needs to be used as well. This means that
> the GCC multilib setup has to be configured to include soft float and
> build coresponding version of libgcc and target fragments.
> But why would we want to generate code without SPE for e500v1/v2? 
> Soft-float comes with a major performance penalty.
> 
> Maybe I didn't understand correctly what kind of toolchain you want to
> be built in the end. Do you want to have a single GCC that builds all
> powerpc targets (e500v2, e5500, e6500 etc) and a separate sysroot for each 
> target? 

Yes, this is exactly what is wanted. This is how the SDK is intended to
operate. The alternative and what we had before was a separate compiler
for each target which is rather wasteful.

> This may be problematic since, for example, the compiler that can generate 
> SPE (for e500v2) can't generate altivec instructions (for e6500).

Is there no way to configure gcc so it can generate for the different
targets assuming you pass in the right runtime target options?

Cheers,

Richard
Khem Raj - Jan. 21, 2014, 5:59 p.m.
On Saturday, January 18, 2014 11:20:07 AM Richard Purdie wrote:
> On Fri, 2014-01-17 at 14:43 +0000, alexandru.sardan@freescale.com wrote:
> > 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).
> 
> The key question is this:
> 
> Can one gcc binary generate code for both non-SPE and SPE targets,
> assuming its pointed at an appropriate sysroot containing appropriate
> libraries?
> 
> If we can have one such binary, how do we configure it? If we can't, we
> need to redo the way gcc-cross-canadian is working on powerpc.
> 

I think gcc can generate the code all you would need is option, real problem
is gcc runtime which will need different set of libraries and init files.


> The change there was to have one gcc for each different target
> architecture rather than each "tune" since that was horribly
> inefficient.
> 

We dont need specific to tune but spe is ABI identifier that should be treated 
differently then defaul tunes IMO

> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Alexandru-Cezar Sardan - Jan. 23, 2014, 6:22 p.m.
Hi,

See my comment inline.

Alex

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Tuesday, January 21, 2014 7:43 PM
> To: Sardan Alexandru Cezar-B41700
> Cc: Udma Catalin-Dan-B32721; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> linux verses linux-gnuspe"
> 
> On Tue, 2014-01-21 at 17:39 +0000, alexandru.sardan@freescale.com wrote:
> > Yes, the gcc configured for SPE (--target=powerpc-fsl_networking-linux-
> gnuspe)
> > can generate both SPE and non-SPE code provided that software
> > floating point is used.
> >
> > There are a couple of parameters (-mabi=no-spe -mno-spe) that will turn
> > off SPE vector instructions generation. If the code contains floating
> > point arithmethic -msoft-float needs to be used as well. This means
> that
> > the GCC multilib setup has to be configured to include soft float and
> > build coresponding version of libgcc and target fragments.
> > But why would we want to generate code without SPE for e500v1/v2?
> > Soft-float comes with a major performance penalty.
> >
> > Maybe I didn't understand correctly what kind of toolchain you want to
> > be built in the end. Do you want to have a single GCC that builds all
> > powerpc targets (e500v2, e5500, e6500 etc) and a separate sysroot for
> each
> > target?
> 
> Yes, this is exactly what is wanted. This is how the SDK is intended to
> operate. The alternative and what we had before was a separate compiler
> for each target which is rather wasteful.
> 
> > This may be problematic since, for example, the compiler that can
> generate
> > SPE (for e500v2) can't generate altivec instructions (for e6500).
> 
> Is there no way to configure gcc so it can generate for the different
> targets assuming you pass in the right runtime target options?

[Alex Sardan] No. The more generic target powerpc-none-linux will not
generate SPE code and the powerpc-none-linux-gnuspe target that generates
SPE will not be able to generate Altivec.
Maybe an exception can be added for e500v1/v2 targets so that a separate
compiler can be generated for them? All the other targets will work fine
with powerpc-none-linux using different runtime command line options.

> 
> Cheers,
> 
> Richard
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
Richard Purdie - Jan. 24, 2014, 3:37 p.m.
On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan@freescale.com wrote:
> > > Maybe I didn't understand correctly what kind of toolchain you want to
> > > be built in the end. Do you want to have a single GCC that builds all
> > > powerpc targets (e500v2, e5500, e6500 etc) and a separate sysroot for
> > each
> > > target?
> > 
> > Yes, this is exactly what is wanted. This is how the SDK is intended to
> > operate. The alternative and what we had before was a separate compiler
> > for each target which is rather wasteful.
> > 
> > > This may be problematic since, for example, the compiler that can
> > generate
> > > SPE (for e500v2) can't generate altivec instructions (for e6500).
> > 
> > Is there no way to configure gcc so it can generate for the different
> > targets assuming you pass in the right runtime target options?
> 
> [Alex Sardan] No. The more generic target powerpc-none-linux will not
> generate SPE code and the powerpc-none-linux-gnuspe target that generates
> SPE will not be able to generate Altivec.
> Maybe an exception can be added for e500v1/v2 targets so that a separate
> compiler can be generated for them? All the other targets will work fine
> with powerpc-none-linux using different runtime command line options.

An exception can probably be added (its all just software after all) but
the setup we have right now just allows for one compiler so some work
will be needed to make this work properly.

Cheers,

Richard
Phil Blundell - Jan. 24, 2014, 8:56 p.m.
On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan@freescale.com wrote:
> [Alex Sardan] No. The more generic target powerpc-none-linux will not
> generate SPE code and the powerpc-none-linux-gnuspe target that generates
> SPE will not be able to generate Altivec.

Why not?  As far as I can tell from the gcc configury, the target string
only affects the defaults (i.e. powerpc-*-linux gets -mno-spe
-mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and
powerpc-*-linuxspe gets -mno-altivec -mspe).  There doesn't seem to be
any real impact beyond this that would make the compiler binary
fundamentally incapable of generating either type of instruction if you
pass the appropriate options on the command line.

p.
Alexandru-Cezar Sardan - Jan. 28, 2014, 2:03 p.m.
Hi,

See my comment inline.

Regards,
Alex

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, January 24, 2014 10:56 PM
> To: Sardan Alexandru Cezar-B41700
> Cc: Udma Catalin-Dan-B32721; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> linux verses linux-gnuspe"
> 
> On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan@freescale.com wrote:
> > [Alex Sardan] No. The more generic target powerpc-none-linux will not
> > generate SPE code and the powerpc-none-linux-gnuspe target that
> generates
> > SPE will not be able to generate Altivec.
> 
> Why not?  As far as I can tell from the gcc configury, the target string
> only affects the defaults (i.e. powerpc-*-linux gets -mno-spe
> -mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and
> powerpc-*-linuxspe gets -mno-altivec -mspe).  There doesn't seem to be
> any real impact beyond this that would make the compiler binary
> fundamentally incapable of generating either type of instruction if you
> pass the appropriate options on the command line.
> 
> p.
[Alex Sardan] Trying to generate altivec instructions with the spe compiler
will yield the following error:

b41700@fsr-ub1264-102: [sandbox]$ powerpc-fsl_networking-linux-gnuspe-gcc -mcpu=e6500 -mabi=no-spe -mno-spe -mabi=altivec -maltivec -S -c double.c 
double.c:1:0: error: AltiVec and E500 instructions cannot coexist

Also trying to generate e500v2 code with powerpc-linux target:

b41700@fsr-ub1264-102: [sandbox]$ powerpc-poky-linux-gcc -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double -S -c double.c 
double.c:1:0: error: not configured for SPE ABI
 double foo()
 ^
double.c:1:0: error: not configured for SPE instruction set

> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
Richard Purdie - Jan. 29, 2014, 11:38 a.m.
On Fri, 2014-01-24 at 20:56 +0000, Phil Blundell wrote:
> On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan@freescale.com wrote:
> > [Alex Sardan] No. The more generic target powerpc-none-linux will not
> > generate SPE code and the powerpc-none-linux-gnuspe target that generates
> > SPE will not be able to generate Altivec.
> 
> Why not?  As far as I can tell from the gcc configury, the target string
> only affects the defaults (i.e. powerpc-*-linux gets -mno-spe
> -mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and
> powerpc-*-linuxspe gets -mno-altivec -mspe).  There doesn't seem to be
> any real impact beyond this that would make the compiler binary
> fundamentally incapable of generating either type of instruction if you
> pass the appropriate options on the command line.

I had a closer look at this. The config.gcc case statements for powerpc
only appear to let you include rs6000/linuxaltivec.h or
rs6000/linuxspe.h, there doesn't appear to be a target you can pass in
to get both.

Looking at the code in those files, I don't see any reason why you can't
actually include support for both however. As such, I just hacked a
build with:

tm_file="${tm_file} rs6000/linuxaltivec.h"
tm_file="${tm_file} rs6000/linuxspe.h rs6000/e500.h"

and it certainly seems to build ok and compile things (this was just for
qemuppc). I didn't try building altivec or spe specific things but
looking at the code, I can't see any reason it wouldn't work at least in
theory.

I'd suggest the easiest way to resolve this may be to patch gcc to
include support for all the modes.

Cheers,

Richard
Alexandru-Cezar Sardan - Jan. 31, 2014, 5:53 p.m.
Hi Richard,

I've tested your patch for both altivec and spe and it works fine.

Regards,
Alex

> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> Sent: Wednesday, January 29, 2014 1:39 PM
> To: Phil Blundell
> Cc: Sardan Alexandru Cezar-B41700; Udma Catalin-Dan-B32721; openembedded-
> core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> linux verses linux-gnuspe"
> 
> On Fri, 2014-01-24 at 20:56 +0000, Phil Blundell wrote:
> > On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan@freescale.com
> wrote:
> > > [Alex Sardan] No. The more generic target powerpc-none-linux will not
> > > generate SPE code and the powerpc-none-linux-gnuspe target that
> generates
> > > SPE will not be able to generate Altivec.
> >
> > Why not?  As far as I can tell from the gcc configury, the target
> string
> > only affects the defaults (i.e. powerpc-*-linux gets -mno-spe
> > -mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and
> > powerpc-*-linuxspe gets -mno-altivec -mspe).  There doesn't seem to be
> > any real impact beyond this that would make the compiler binary
> > fundamentally incapable of generating either type of instruction if you
> > pass the appropriate options on the command line.
> 
> I had a closer look at this. The config.gcc case statements for powerpc
> only appear to let you include rs6000/linuxaltivec.h or
> rs6000/linuxspe.h, there doesn't appear to be a target you can pass in
> to get both.
> 
> Looking at the code in those files, I don't see any reason why you can't
> actually include support for both however. As such, I just hacked a
> build with:
> 
> tm_file="${tm_file} rs6000/linuxaltivec.h"
> tm_file="${tm_file} rs6000/linuxspe.h rs6000/e500.h"
> 
> and it certainly seems to build ok and compile things (this was just for
> qemuppc). I didn't try building altivec or spe specific things but
> looking at the code, I can't see any reason it wouldn't work at least in
> theory.
> 
> I'd suggest the easiest way to resolve this may be to patch gcc to
> include support for all the modes.
> 
> Cheers,
> 
> Richard
> 
>
Richard Purdie - Jan. 31, 2014, 6:07 p.m.
On Fri, 2014-01-31 at 17:53 +0000, alexandru.sardan@freescale.com wrote:
> Hi Richard,
> 
> I've tested your patch for both altivec and spe and it works fine.

Would you be able to put together a proper patch with the explanation
and so on so we can get it merged and resolve this issue?

Cheers,

Richard

> Regards,
> Alex
> 
> > -----Original Message-----
> > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > Sent: Wednesday, January 29, 2014 1:39 PM
> > To: Phil Blundell
> > Cc: Sardan Alexandru Cezar-B41700; Udma Catalin-Dan-B32721; openembedded-
> > core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> > linux verses linux-gnuspe"
> > 
> > On Fri, 2014-01-24 at 20:56 +0000, Phil Blundell wrote:
> > > On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan@freescale.com
> > wrote:
> > > > [Alex Sardan] No. The more generic target powerpc-none-linux will not
> > > > generate SPE code and the powerpc-none-linux-gnuspe target that
> > generates
> > > > SPE will not be able to generate Altivec.
> > >
> > > Why not?  As far as I can tell from the gcc configury, the target
> > string
> > > only affects the defaults (i.e. powerpc-*-linux gets -mno-spe
> > > -mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and
> > > powerpc-*-linuxspe gets -mno-altivec -mspe).  There doesn't seem to be
> > > any real impact beyond this that would make the compiler binary
> > > fundamentally incapable of generating either type of instruction if you
> > > pass the appropriate options on the command line.
> > 
> > I had a closer look at this. The config.gcc case statements for powerpc
> > only appear to let you include rs6000/linuxaltivec.h or
> > rs6000/linuxspe.h, there doesn't appear to be a target you can pass in
> > to get both.
> > 
> > Looking at the code in those files, I don't see any reason why you can't
> > actually include support for both however. As such, I just hacked a
> > build with:
> > 
> > tm_file="${tm_file} rs6000/linuxaltivec.h"
> > tm_file="${tm_file} rs6000/linuxspe.h rs6000/e500.h"
> > 
> > and it certainly seems to build ok and compile things (this was just for
> > qemuppc). I didn't try building altivec or spe specific things but
> > looking at the code, I can't see any reason it wouldn't work at least in
> > theory.
> > 
> > I'd suggest the easiest way to resolve this may be to patch gcc to
> > include support for all the modes.
> > 
> > Cheers,
> > 
> > Richard
> > 
> > 
> 
>
Alexandru-Cezar Sardan - Jan. 31, 2014, 6:17 p.m.
Hi,

Sure, I'll do this and also some more extensive testing
on the boards.

Thanks,
Alex

> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> Sent: Friday, January 31, 2014 8:07 PM
> To: Sardan Alexandru Cezar-B41700
> Cc: Phil Blundell; Udma Catalin-Dan-B32721; openembedded-
> core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> linux verses linux-gnuspe"
> 
> On Fri, 2014-01-31 at 17:53 +0000, alexandru.sardan@freescale.com wrote:
> > Hi Richard,
> >
> > I've tested your patch for both altivec and spe and it works fine.
> 
> Would you be able to put together a proper patch with the explanation
> and so on so we can get it merged and resolve this issue?
> 
> Cheers,
> 
> Richard
> 
> > Regards,
> > Alex
> >
> > > -----Original Message-----
> > > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > > Sent: Wednesday, January 29, 2014 1:39 PM
> > > To: Phil Blundell
> > > Cc: Sardan Alexandru Cezar-B41700; Udma Catalin-Dan-B32721;
> openembedded-
> > > core@lists.openembedded.org
> > > Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> > > linux verses linux-gnuspe"
> > >
> > > On Fri, 2014-01-24 at 20:56 +0000, Phil Blundell wrote:
> > > > On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan@freescale.com
> > > wrote:
> > > > > [Alex Sardan] No. The more generic target powerpc-none-linux will
> not
> > > > > generate SPE code and the powerpc-none-linux-gnuspe target that
> > > generates
> > > > > SPE will not be able to generate Altivec.
> > > >
> > > > Why not?  As far as I can tell from the gcc configury, the target
> > > string
> > > > only affects the defaults (i.e. powerpc-*-linux gets -mno-spe
> > > > -mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and
> > > > powerpc-*-linuxspe gets -mno-altivec -mspe).  There doesn't seem to
> be
> > > > any real impact beyond this that would make the compiler binary
> > > > fundamentally incapable of generating either type of instruction if
> you
> > > > pass the appropriate options on the command line.
> > >
> > > I had a closer look at this. The config.gcc case statements for
> powerpc
> > > only appear to let you include rs6000/linuxaltivec.h or
> > > rs6000/linuxspe.h, there doesn't appear to be a target you can pass
> in
> > > to get both.
> > >
> > > Looking at the code in those files, I don't see any reason why you
> can't
> > > actually include support for both however. As such, I just hacked a
> > > build with:
> > >
> > > tm_file="${tm_file} rs6000/linuxaltivec.h"
> > > tm_file="${tm_file} rs6000/linuxspe.h rs6000/e500.h"
> > >
> > > and it certainly seems to build ok and compile things (this was just
> for
> > > qemuppc). I didn't try building altivec or spe specific things but
> > > looking at the code, I can't see any reason it wouldn't work at least
> in
> > > theory.
> > >
> > > I'd suggest the easiest way to resolve this may be to patch gcc to
> > > include support for all the modes.
> > >
> > > Cheers,
> > >
> > > Richard
> > >
> > >
> >
> >
> 
> 
>
David Nyström - Feb. 11, 2014, 10:07 a.m.
On 2014-01-31 19:17, alexandru.sardan@freescale.com wrote:
> Hi,
>
> Sure, I'll do this and also some more extensive testing
> on the boards.
>
> Thanks,
> Alex
>

Hi Alex,

Whats the status on this ?

Br,
David
Alexandru-Cezar Sardan - Feb. 26, 2014, 6:29 p.m.
Hi David,

Sorry for the late reply.
I'm not familiar with the procedure for submitting a patch to Poky. 
Could you walk me through the process?

Meanwhile I've attached the patch to this e-mail. It's been tested
on e500v2, e5500 and e6500.

Kind regards,
Alex


> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> David Nyström
> Sent: Tuesday, February 11, 2014 12:08 PM
> To: Sardan Alexandru Cezar-B41700; Richard Purdie
> Cc: Udma Catalin-Dan-B32721; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> linux verses linux-gnuspe"
> 
> On 2014-01-31 19:17, alexandru.sardan@freescale.com wrote:
> > Hi,
> >
> > Sure, I'll do this and also some more extensive testing
> > on the boards.
> >
> > Thanks,
> > Alex
> >
> 
> Hi Alex,
> 
> Whats the status on this ?
> 
> Br,
> David
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
David Nyström - Feb. 26, 2014, 10:37 p.m.
On 2014-02-26 19:29, alexandru.sardan@freescale.com wrote:
> Hi David,
>
> Sorry for the late reply.
> I'm not familiar with the procedure for submitting a patch to Poky.
> Could you walk me through the process?
>
> Meanwhile I've attached the patch to this e-mail. It's been tested
> on e500v2, e5500 and e6500.
>
> Kind regards,
> Alex

Hi,

You patch looks fine to me. A couple of comments though:

You should use git send-mail to send it to oe-core, and your patch on 
GCC needs an upstream status.
i.e. Plans of how and if this will be upstreamed to GCC.

Details:
https://wiki.yoctoproject.org/wiki/Contribution_Guidelines

Was able to build a working SDK compiler for p1025twr.

When this has brewed in the Autobuilder for a while, it should be 
backported to dora as well.

Br,
David


>
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> David Nyström
>> Sent: Tuesday, February 11, 2014 12:08 PM
>> To: Sardan Alexandru Cezar-B41700; Richard Purdie
>> Cc: Udma Catalin-Dan-B32721; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
>> linux verses linux-gnuspe"
>>
>> On 2014-01-31 19:17, alexandru.sardan@freescale.com wrote:
>>> Hi,
>>>
>>> Sure, I'll do this and also some more extensive testing
>>> on the boards.
>>>
>>> Thanks,
>>> Alex
>>>
>> Hi Alex,
>>
>> Whats the status on this ?
>>
>> Br,
>> David
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Alexandru-Cezar Sardan - Feb. 27, 2014, 12:21 p.m.
Hi,

I've made the modifications and sent the patch with git send-mail to the oe-core list.

Regards,
Alex


From: David Nyström [mailto:david.c.nystrom@gmail.com]
Sent: Thursday, February 27, 2014 12:37 AM
To: Sardan Alexandru Cezar-B41700; David Nyström; Richard Purdie
Cc: Udma Catalin-Dan-B32721; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe"


On 2014-02-26 19:29, alexandru.sardan@freescale.com<mailto:alexandru.sardan@freescale.com> wrote:

Hi David,



Sorry for the late reply.

I'm not familiar with the procedure for submitting a patch to Poky.

Could you walk me through the process?



Meanwhile I've attached the patch to this e-mail. It's been tested

on e500v2, e5500 and e6500.



Kind regards,

Alex

Hi,

You patch looks fine to me. A couple of comments though:

You should use git send-mail to send it to oe-core, and your patch on GCC needs an upstream status.
i.e. Plans of how and if this will be upstreamed to GCC.

Details:
https://wiki.yoctoproject.org/wiki/Contribution_Guidelines

Was able to build a working SDK compiler for p1025twr.

When this has brewed in the Autobuilder for a while, it should be backported to dora as well.

Br,
David










-----Original Message-----

From: openembedded-core-bounces@lists.openembedded.org<mailto:openembedded-core-bounces@lists.openembedded.org>

[mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of

David Nyström

Sent: Tuesday, February 11, 2014 12:08 PM

To: Sardan Alexandru Cezar-B41700; Richard Purdie

Cc: Udma Catalin-Dan-B32721; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>

Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc

linux verses linux-gnuspe"



On 2014-01-31 19:17, alexandru.sardan@freescale.com<mailto:alexandru.sardan@freescale.com> wrote:

Hi,



Sure, I'll do this and also some more extensive testing

on the boards.



Thanks,

Alex





Hi Alex,



Whats the status on this ?



Br,

David

Patch

diff --git a/meta/classes/cross-canadian.bbclass b/meta/classes/cross-canadian.bbclass
index c974212..7181c60 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -15,30 +15,12 @@  STAGING_BINDIR_TOOLCHAIN = "${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S
 # Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
 #
 PACKAGE_ARCH = "${SDK_ARCH}-${SDKPKGSUFFIX}"
-CANADIANEXTRAOS = ""
 python () {
     archs = d.getVar('PACKAGE_ARCHS', True).split()
     sdkarchs = []
     for arch in archs:
         sdkarchs.append(arch + '-${SDKPKGSUFFIX}')
     d.setVar('PACKAGE_ARCHS', " ".join(sdkarchs))
-
-    # PowerPC can build "linux" and "linux-gnuspe"
-    tarch = d.getVar("TARGET_ARCH", True)
-    if tarch == "powerpc":
-        tos = d.getVar("TARGET_OS", True)
-        if (tos != "linux" and tos != "linux-gnuspe"):
-            bb.fatal("Building cross-candian powerpc for an unknown TARGET_SYS (%s), please update cross-canadian.bbclass" % d.getVar("TARGET_SYS", True))
-        # Have to expand DEPENDS before we change the extensions
-        d.setVar("DEPENDS", d.getVar("DEPENDS", True))
-        d.setVar("STAGING_BINDIR_TOOLCHAIN", d.getVar("STAGING_BINDIR_TOOLCHAIN", True))
-        for prefix in ["AR", "AS", "DLLTOOL", "CC", "CXX", "GCC", "LD", "LIPO", "NM", "OBJDUMP", "RANLIB", "STRIP", "WINDRES"]:
-            n = prefix + "_FOR_TARGET"
-            d.setVar(n, d.getVar(n, True))
-
-        d.setVar("LIBCEXTENSION", "")
-        d.setVar("ABIEXTENSION", "")
-        d.setVar("CANADIANEXTRAOS", "linux-gnuspe")
 }
 MULTIMACH_TARGET_SYS = "${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
 
@@ -118,16 +100,3 @@  TARGET_ARCH[vardepsexclude] = "TUNE_ARCH"
 # points to the wrong place so force it
 SHLIBSDIRS = "${PKGDATA_DIR}/nativesdk-shlibs"
 SHLIBSWORKDIR = "${PKGDATA_DIR}/nativesdk-shlibs"
-
-cross_canadian_bindirlinks () {
-	for i in ${CANADIANEXTRAOS}
-	do
-		d=${D}${bindir}/../${TARGET_ARCH}${TARGET_VENDOR}-$i
-		install -d $d
-		for j in `ls ${D}${bindir}`
-		do
-			p=${TARGET_ARCH}${TARGET_VENDOR}-$i-`echo $j | sed -e s,${TARGET_PREFIX},,`
-			ln -s ../${TARGET_SYS}/$j $d/$p
-		done
-       done
-}
diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
index 81349c0..2da9017 100644
--- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
+++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
@@ -22,8 +22,6 @@  do_install () {
 	rm -f ${D}${libdir}/libiberty*
 	rm -f ${D}${libdir}/libopcodes*
 	rm -f ${D}${includedir}/*.h
-	
-	cross_canadian_bindirlinks
 }
 
 BBCLASSEXTEND = ""
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index 900f1e5..64bb6ba 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -29,7 +29,6 @@  export AS_FOR_TARGET = "${TARGET_PREFIX}as"
 export DLLTOOL_FOR_TARGET = "${TARGET_PREFIX}dlltool"
 export CC_FOR_TARGET = "${TARGET_PREFIX}gcc"
 export CXX_FOR_TARGET = "${TARGET_PREFIX}g++"
-export GCC_FOR_TARGET = "${TARGET_PREFIX}gcc"
 export LD_FOR_TARGET = "${TARGET_PREFIX}ld"
 export LIPO_FOR_TARGET = "${TARGET_PREFIX}lipo"
 export NM_FOR_TARGET = "${TARGET_PREFIX}nm"
@@ -70,7 +69,7 @@  EXCLUDE_FROM_SHLIBS = "1"
 PACKAGES = "${PN} ${PN}-doc"
 
 FILES_${PN} = "\
-    ${exec_prefix}/bin/* \
+    ${bindir}/* \
     ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/* \
     ${gcclibdir}/${TARGET_SYS}/${BINV}/*.o \
     ${gcclibdir}/${TARGET_SYS}/${BINV}/specs \
@@ -138,8 +137,6 @@  do_install () {
 	done
 
 	chown -R root:root ${D}
-	
-	cross_canadian_bindirlinks
 }
 
 ELFUTILS = "nativesdk-elfutils"
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
index 653f52b..3cb347b 100644
--- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
+++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
@@ -31,6 +31,5 @@  EOF
 # right bits installed by binutils.
 do_install_append() {
 	rm -rf ${D}${exec_prefix}/lib
-	cross_canadian_bindirlinks
 }