PS3 I updated the ps3toolchain to gcc 9.5.0/binutils 2.40

disc-kuraudo.eu

disc-kuraudo.eu

Member
Hey there.

I updated the ps3toolchain (w/o gdb and ps3libraries yet) to gcc 9.5.0 (PPU/SPU), binutils to 2.40 (PPU).
Chose 9.5.0 as this marks the last gcc release with (deprecated) SPU support. Will check out bumping the PPU gcc to version 13 once that's out.
Skipped on C++ and bumping SPU binutils because I encountered some issues and I don't really need this.
Can tell it produces much better machine code than gcc <=7.2.0 even with simple things like a custom memcpy.

https://aur.archlinux.org/packages/ps3toolchain
(Meta package, the components are under Dependencies)

Feel free to test it out and whoever is behind the ps3dev github to use the patches once stable enough.
 
Last edited:
Didn't get as far as I liked regarding adding the libraries.

However, I prepared an Arch Linux Live ISO image that contains the ps3toolchain and (incomplete) ps3libraries for trying out in a VM, 2nd rig, laptop, etc.:
https://disc-kuraudo.eu/releases/archiso-dk-current-x86_64.iso

Notes: Diskless image, copies the entire thing of ~2.5GB to RAM. 4GB RAM recommended. I am using it on my 2nd rig with ~3.3GB RAM myself for dumping discs.

Once booted:
Code: 
$ module load ps3toolchain ps3libraries
$ ppu-gcc --version
ppu-gcc (GCC) 9.5.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
disc-kuraudo.eu said:
Hey there.

I updated the ps3toolchain (w/o gdb and ps3libraries yet) to gcc 9.5.0 (PPU/SPU), binutils to 2.40 (PPU).
Chose 9.5.0 as this marks the last gcc release with (deprecated) SPU support. Will check out bumping the PPU gcc to version 13 once that's out.
Skipped on C++ and bumping SPU binutils because I encountered some issues and I don't really need this.
Can tell it produces much better machine code than gcc <=7.2.0 even with simple things like a custom memcpy.

https://aur.archlinux.org/packages/ps3toolchain
(Meta package, the components are under Dependencies)

Feel free to test it out and whoever is behind the ps3dev github to use the patches once stable enough.
Click to expand...
Is PPU support still not removed? I thought that when removing the one from the SPU, they would remove the one from the PPU along with it, and is it okay to compile on two different versions of GCC?
 
disc-kuraudo.eu said:
PPU is essentially PowerPC64 with Power ISA Version 2.03 which is the same as built in the PowerMac G5 CPUs.
Don't think that's going anywhere for now.

Can also look into the code:
https://github.com/gcc-mirror/gcc/b...e9d58bd5d98b4/gcc/config/rs6000/rs6000.h#L123
Click to expand...
Oh I see, removing this would also remove it for the PowerMac (which may still be in use), good then, about the SPU, there is the possibility of returning compatibility with the latest GCC by patching the files as there is in the PPU by example?
 
luizfernandonb said:
good then, about the SPU, there is the possibility of returning compatibility with the latest GCC by patching the files as there is in the PPU by example?
Click to expand...
Theoretically, but quite the effort. Here's the commit that removed it:
https://gcc.gnu.org/git/?p=gcc.git;...5195f6eb5e23516ae12618c9f82&utm_source=anzwix
273 files changed, around half of that deleted, the other half was interweaved with the code that probably changed over time already.

Since there's barely demand for this compiler (don't know of any homebrew that does) and the gains of re-enabling this somehow on e.g. GCC 13.x are minimal (maybe slightly better optimization passes in the middle-end and some new C and C++ language features), there's not much incentive to do this.

Here also some article about dropping the support from 2019:
https://www.phoronix.com/news/GCC-10-Drops-Cell-BE-SPU
 
Last edited:
disc-kuraudo.eu said:
Didn't get as far as I liked regarding adding the libraries.

However, I prepared an Arch Linux Live ISO image that contains the ps3toolchain and (incomplete) ps3libraries for trying out in a VM, 2nd rig, laptop, etc.:
https://disc-kuraudo.eu/releases/archiso-dk-current-x86_64.iso

Notes: Diskless image, copies the entire thing of ~2.5GB to RAM. 4GB RAM recommended. I am using it on my 2nd rig with ~3.3GB RAM myself for dumping discs.

Once booted:
Code: 
$ module load ps3toolchain ps3libraries
$ ppu-gcc --version
ppu-gcc (GCC) 9.5.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Click to expand...

I ran it in a virtual machine and tried to compile a test file but it gives this error, both in ppu and spu
upload_2023-5-4_19-35-28.png
 

Attachments

  • upload_2023-5-4_19-34-23.png
    upload_2023-5-4_19-34-23.png
    12.9 KB · Views: 51
Last edited:
Updated ISO (the previous link works as well as it now points to this):
https://disc-kuraudo.eu/releases/archiso-dk-2023.05.06-x86_64.iso
Edit: fresh rebuild using GCC 13.1.1 and has disc-kuraudo-home 0.3.4 hotfix.

Turns out it didn't even touch the prerequisite tarballs that are manually downloaded.
Forgot to invoke a script that puts their contents in their place so they are built internally and no longer need to be provided from the outside.
 
Last edited:
disc-kuraudo.eu said:
Updated ISO (the previous link works as well as it now points to this):
https://disc-kuraudo.eu/releases/archiso-dk-2023.05.05-x86_64.iso

Turns out it didn't even touch the prerequisite tarballs that are manually downloaded.
Forgot to invoke a script that puts their contents in their place so they are built internally and no longer need to be provided from the outside.
Click to expand...

I tested it and it compiles perfectly with spu-gcc without errors, but when compiling using ppu-gcc it gives an error in ld, but the executable is created
upload_2023-5-5_17-57-0.png
 
and I tried to compile the gcc that you made in Arch Linux in Ubuntu, but when compiling PSL1GHT, it gives this error, did I forget to do something? Have you ever had this error? If you can help me I appreciate it
upload_2023-5-6_1-26-23.png
 
Yeah I experienced this as well and worked it around:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ps3-psl1ght#n31

Seems stable building huge libraries like FFmpeg with hundreds of C files but fails there somehow with specific optimization levels, no idea.

About the crtend.o error(warning), looking into it.
Somehow apparently related to C++ exeptions which doesn't make sense to me as I disabled C++ (as libstdc++ failed to build iirc).
:sco hmmthink:
 
Last edited:
disc-kuraudo.eu said:
Yeah I experienced this as well and worked it around:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ps3-psl1ght#n31

Seems stable building huge libraries like FFmpeg with hundreds of C files but fails there somehow with specific optimization levels, no idea.

About the crtend.o error(warning), looking into it.
Somehow apparently related to C++ exeptions which doesn't make sense to me as I disabled C++ (as libstdc++ failed to build iirc).
:sco hmmthink:
Click to expand...
About crtend.o, is this a bug of this specific version of GCC? If so, wouldn't it be better to rollback to a 9.3 or 9.4 version? Or one where you don't have this error
 
I was able to get GCC 9.5.0/binutils 2.40 to compile for the SPU, found out the problem was the GCC optimizations, none of the flags worked (-O1, -O2, -O3, and -Ofast), only worked if disabled with - O0, but using -O0 in some specific points of the compilation, not in everything, honestly this is very strange but in the end everything works and the GCC for the SPU is compiled without problems and works perfectly, follow the step-by-step:

1. Configure GCC normally with the flags
2. Run make
3. When compilation fails, patch with "patch_spu_gcc1.patch" file
> patch -p1 < patch_spu_gcc1.patch
4. Run make again
5. When compilation fails, patch with "patch_spu_gcc2.patch" file
> patch -p1 < patch_spu_gcc2.patch
6. Run make again
7. When compilation fails, patch with "patch_spu_gcc3.patch" file
> patch -p1 < patch_spu_gcc3.patch
8. Run make again
9. If everything went correctly, GCC has finished compiling and you can run make install to install it

PS: Patch files are attached here
PS2: When downloading patches, please rename them to .patch extension, this forum won't let me attach the file as .patch
PS3: In the patch "patch_spu_gcc1" I removed the -g flag, GCC puts it by default I don't know why, but I removed it, you can put it back if you want, it doesn't generate the error
 

Attachments

I've already researched a lot about the crtend.o error and I've already messed with a lot of things in GCC/binutils and haven't found out what it is, but I found something curious, if you ask GCC not to call ld and you call it manually, theoretically everything works, follow the step-by-step code:

1. Compile any example file having the -c option in the command, example:
> ppu-gcc test.c -c
this will generate a test.o file
2. Link manually by calling ppu-ld with this command:
> ppu-ld test.o --entry main -o test
the executable is theoretically the same, I didn't run it to test it, but it didn't generate any error or warning, the only special option is to specify the entry

Strange isn't it? I have the impression that GCC is calling ld with wrong options, I'm not sure, I haven't figured out how to see that
 
You must log in or register to reply here.

Similar threads

Back
Top