Cross toolchain support for SPUs on Cell / ppc64

[Jochen Roth]

A lot of people using the PS3 and / or Cell based systems suffer from 
missing toolchain support for building SPU applications just after they 
installed Fedora. They have to download the necessary packages from 
various places and have to do the package management by their own.

I think that the time is right to support SPUs right out of the box 
after installing the latest Fedora release. Therefore we'd need to have 
the following packages in Fedora.

spu-binutils
spu-gcc
spu-newlib
spu-gdb

Before we start opening Review Requests in Bugzilla we want to start the 
discussion what the best approach for supporting cross compiling 
toolchains like the SPU toolchain in Fedora is. As far as I know there 
is only one example for cross compiler support in Fedora which is Atmels 
AVR.

Our suggestion would be to build spu-binutils from the same source as 
the system gcc for ppc is build. Here we'd have to change the ppc 
binutils package and add --enable-target=spu . A separate spu-binutils 
package including the spu assembly is needed anyhow.

It would also be good to be able to build the spu-gcc from the same 
sources as the system gcc is build. It would be even better if the 
spu-gcc is build from the same .spec file. Of course this needs a lot of 
configuration and adjustments.

For spu-newlib we'd have to create a separate package as we'd have for 
spu-gdb.

Thanks for any comment, suggestion and help.

-- 

Jochen

[Ralf Corsepius]

On Fri, 2008-06-20 at 20:55 +0200, Jochen Roth wrote:

>  Before we start opening Review Requests in Bugzilla we want to start
> the 
>  discussion what the best approach for supporting cross compiling 
>  toolchains like the SPU toolchain in Fedora is. As far as I know there 
>  is only one example for cross compiler support in Fedora which is Atmels 
>  AVR.
>  
>  Our suggestion would be to build spu-binutils from the same source as 
>  the system gcc for ppc is build. 
Theoretically, this would be one possibility,
however, practice tells
this doesn't work, because there always will be situations when you will
want to patch/apply hacks to your cross-binutils, or when
target-specific bugs force your cross-binutils to use a different
version of binutils than of the native binutils.

>   Here we'd have to change the ppc 
>  binutils package and add --enable-target=spu . A separate spu-binutils 
>  package including the spu assembly is needed anyhow. 
The latter is what I have
learned to be the only viable approach.

>  It would also be good to be able to build the spu-gcc from the same 
>  sources as the system gcc is build. 
IMO, this doesn't work for the same
rationales as above.

>   It would be even better if the 
>  spu-gcc is build from the same .spec file. Of course this needs a lot of 
>  configuration and adjustments. 
Yes, building cross-toolchain packages is tedious.

>  For spu-newlib we'd have to create a separate package as we'd
> have for 
>  spu-gdb. 
This is one option, but it raises problems with bootstrapping GCC.

The alternative is building newlib+gcc one-tree-style (building newlib
and gcc at the same time). It's what I do for my cross-toolchains.

Ralf

[Jochen Roth]

Ralf Corsepius wrote:
> > Our suggestion would be to build spu-binutils from the same
> source as 
> > the system gcc for ppc is build.
>  Theoretically, this would be one possibility, however, practice tells
>  this doesn't work, because there always will be situations when you will
>  want to patch/apply hacks to your cross-binutils, or when
>  target-specific bugs force your cross-binutils to use a different
>  version of binutils than of the native binutils. 
Yes, we need a separate spu-binutils package for the assembly anyway.
And then we can build the spu-binutils from the same source tree as the 
systems binutils package. And of course add some patches for target 
specific bugs if needed. I think this is also the way avr-binutils does.

The systems binutils package has to be compiled with at least the option 
--enable-target=spu or even better with --enable-target=all

What is the right directory where SPU include files should go?
I just looked into avr-libc and they put everything in /usr/avr/ ..

So would it be correct to put spu related files in /usr/spu/ and 
subdirectories?

> > For spu-newlib we'd have to create a separate package as
> we'd have for 
> > spu-gdb.
>  This is one option, but it raises problems with bootstrapping GCC.
>  
>  The alternative is building newlib+gcc one-tree-style (building newlib
>  and gcc at the same time). It's what I do for my cross-toolchains. 
Yes, right, that is another thing we have to care about.


Btw, is there any Fedora cross-toolchain guide I should be aware of?

Thanks!

-- 

Jochen

Jochen,
On Sat, 2008-06-21 at 16:21 +0200, Jochen Roth wrote:
>  Ralf Corsepius wrote:
>  >> Our suggestion would be to build spu-binutils from the same source as 
>  >> the system gcc for ppc is build.
>  > Theoretically, this would be one possibility, however, practice tells
>  > this doesn't work, because there always will be situations when you will
>  > want to patch/apply hacks to your cross-binutils,
>  
>  Yes, we need a separate spu-binutils package for the assembly anyway.
>  And then we can build the spu-binutils from the same source tree as the 
>  systems binutils package. 
As you know I have been following an alternative method
of delivering an
spu-binutils package; one of creating a package outside the existing
binutils.spec file.

After experimentation I'm now convinced that your approach is correct.
It is necessary to add a spu-binutils package to the binutils.spec, and
similarly an spu-binutils package to the gcc43.spec.  This ensures that
binutils and spu-binutils share the same .po files and that they are
always at some synchronised correct point release etc...  It would be
far too easy to fall out of sync with binutils if the package was a
separate .spec file.

> From my reading of the matter you and I would both like to see
spu-binutils and spu-gcc pushed into Fedora.  I think both of us are in
the dark about how Fedora would like its cross-compilers packaged and
installed.  Is there a policy on this?  Or could someone who has
experience with Fedora compiler packaging suggest how they would like to
see the packaging done.

--
Aidan Delaney

[Ralf Corsepius]

On Wed, 2008-07-02 at 08:36 +0100, A.J.Delaney(a)brighton.ac.uk wrote:
>  Jochen,
>  On Sat, 2008-06-21 at 16:21 +0200, Jochen Roth wrote:
>  > Ralf Corsepius wrote:
>  > >> Our suggestion would be to build spu-binutils from the same source as 
>  > >> the system gcc for ppc is build.
>  > > Theoretically, this would be one possibility, however, practice tells
>  > > this doesn't work, because there always will be situations when you will
>  > > want to patch/apply hacks to your cross-binutils,
>  > 
>  > Yes, we need a separate spu-binutils package for the assembly anyway.
>  > And then we can build the spu-binutils from the same source tree as the 
>  > systems binutils package. 
>  >From my reading of the matter you and I would both like to see
>  spu-binutils and spu-gcc pushed into Fedora.  I think both of us are in
>  the dark about how Fedora would like its cross-compilers packaged and
>  installed.  Is there a policy on this? 
Nope, there isn't. 

All I can say, I for one don't see any reason for treating
cross-toolchain packages any different from any other packages.
Besides of them facing the bugs in rpm/redhat-rpm-config which happen to
render packaging cross-toolchains difficult, and GCC's installation
directory conventions which happen to clash with the FHS, they are
ordinary applications.

>    Or could someone who has
>  experience with Fedora compiler packaging suggest how they would like to
>  see the packaging done. 
Well, I happen package cross toolchains for Fedora for
quite some
time[1]. Hans's avr packages inherited some aspects from these during
their package review.

Ralf

[1] cf. ftp://ftp.rtems.org/pub/rtems/linux