Upgrade GCC 13.2.0 version (PPU-SPU)

[humbertodias]

Features

• binutils-ppu bumped from 2.22 to 2.42
• ppu-gcc bumped from 7.20 to 13.2.0
• spu-gcc bumped from 7.20 to 9.5.0
• docker bumped from 16.04 to 24.04 - LTS
• ci/cd working again and building releases
• ci/cd to docker hub
• ci/cd badges
• build on ubuntu/macOS for arm64 enabled
• test PSL1GHT hello game

Note

We've selected the version 9.5.0 because it's the last GCC release to include support for SPU.
https://www.phoronix.com/news/GCC-10-Drops-Cell-BE-SPU

Tip

Patches credits to disc-kuraudo and luizfernandonb

Result

1. ar --version

GNU ar (GNU Binutils) 2.42
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

2. ppu-gcc --version

ppu-gcc (GCC) 13.2.0
Copyright (C) 2023 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.

3. spu-gcc --version

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

4. Docker

FROM ubuntu:24.04

5. ci/cd success

https://github.com/humbertodias/ps3toolchain/actions/runs/8166663270

6. ci/cd docker
   

Note

Don't forget to create a named DockerHub environment on your repository with two secret variables: DOCKERHUB_USERNAME and DOCKERHUB_TOKEN

7. badges
   

8. PSL1GHT hello game

[Fewnity]

Hey cool work, I really want gcc 13 on ps3. But you just forgot to credit Darjan Krijanand and luizfernandonb :/

[humbertodias]

Hey cool work, I really want gcc 13 on ps3. But you just forgot to credit Darjan Krijanand and luizfernandonb :/

Yeah.. I left his name on patch's file given him the credit

[Fancy2209]

Could the docker ci be skipped for pull requests?

[humbertodias]

Could the docker ci be skipped for pull requests?

Sure! Skipped 6f580ea

[zeldin]

So, looking at the current "Files changed" for this PR, there are a few unrelated changes here:

• Changes to the CI workflow / Docker image
• Version bump of binutils
• Restoring the gdb builds (@Fancy2209 why were these removed in the first place? The commit message explains nothing.)

These should be made into separate PRs so that they can be reviewed and merged (if appropriate).

In addition there's a bunch of other stuff which I don't think is relevant, like the utils functions to handle config.guess/config.sub replacement (already handled elsewhere). If there are additional things which are still relevant, they should also go into separate pull requests.

Kitchen sink PRs like this one can be useful to try get some testing of a complete set of changes, but they are not conductive to actual merging. 😸

[Fancy2209]

So, looking at the current "Files changed" for this PR, there are a few unrelated changes here:

• Changes to the CI workflow / Docker image
• Version bump of binutils
• Restoring the gdb builds (@Fancy2209 why were these removed in the first place? The commit message explains nothing.)

These should be made into separate PRs so that they can be reviewed and merged (if appropriate).

In addition there's a bunch of other stuff which I don't think is relevant, like the utils functions to handle config.guess/config.sub replacement (already handled elsewhere). If there are additional things which are still relevant, they should also go into separate pull requests.

Kitchen sink PRs like this one can be useful to try get some testing of a complete set of changes, but they are not conductive to actual merging. 😸

GDB was causing issues building on macOS from what I remember and users can install GDB-Multiarch to get the same result, we also have no way to actually use GDB outside RPCS3 from what I know. I can look into restoring it.

[zeldin]

GDB was causing issues building on macOS from what I remember and users can install GDB-Multiarch to get the same result, we also have no way to actually use GDB outside RPCS3 from what I know. I can look into restoring it.

Sounds like a better solution would be to fix the build issues then. Probably there is some upstreams commit that can be backported.

GDB should be able to interact with gdbserver running on hardware I think.

[zeldin]

@magendavid06-cell I do not believe that this should be merged without significant cleanup. This PR has 160 commits with changes to 26 files, none of which are needed to actually implement what the PR says it is for (because that has already gone in though PRs in other repos). Merging this will put the main repo in a very confusing state.

I'm not (at the moment at least 😸) objecting to any specific change still contained in this PR, I'm just saying that the different changes should be squashed and re-published as separate PR:s so that they can be properly reviewed and cleanly merged.

(sorry, had the wrong Github user active at first...)

[TheMrIron2]

@zeldin This person created their account a few hours ago just to approve the changes with no comments. I didn't even know someone could do that until now. I would probably disregard it entirely.

That said, this probably is a reminder this is an important item to raise and get some motion on. I agree with the three separated PRs you mentioned earlier - am I right in saying the next step is we make those PRs, strip out the extraneous features from this one, and then return to this one for a review of GCC? It seems like the core work is done, it just needs procedure.

[zeldin]

@TheMrIron2 The GCC stuff is already done; it was reviewed and merged as ps3dev/gcc-PS3#1. If there is any fallout from it we can handle it with new issues/PRs, I don't think there is any benefit in remitting to this PR. If any input from humbertodias is needed we can tag him.

As for the other changes, yes, I'd say the next step is to make new PR:s. It's a little bit of extra work but it will make the scope of each change clear so that it can be reviewed, tested and merged in isolation. I don't think there are any cross-dependencies.

If humberodias doesn't have the time or energy to do it, it's possible for someone else to pick up the torch; we can still give proper credit in the author field.

[humbertodias]

So, looking at the current "Files changed" for this PR, there are a few unrelated changes here:

* Changes to the CI workflow / Docker image

* Version bump of binutils

* Restoring the gdb builds (@Fancy2209 why were these removed in the first place?  The commit message explains nothing.)

These should be made into separate PRs so that they can be reviewed and merged (if appropriate).

In addition there's a bunch of other stuff which I don't think is relevant, like the utils functions to handle config.guess/config.sub replacement (already handled elsewhere). If there are additional things which are still relevant, they should also go into separate pull requests.

Kitchen sink PRs like this one can be useful to try get some testing of a complete set of changes, but they are not conductive to actual merging. 😸

Hi, sorry for the delay! No problem, I’ve removed the unrelated changes in commit dc48523

[zeldin]

Thanks. Now we have something manageable to review. 😄

Will you make additional PR:s for the binutils bump and/or CI/docker changes?

Let's consider the three parts of what is left in this PR:

1. patches directory
   AFAICT this just amounts to splitting out the cherry-picked host fixes into separate patch files.
   I don't think we need to do this; it's not like we need to exclude the macos host fixes on non-macos systems, and it's pretty clear in the gcc repo what is what.
   However, if we do want to do this, it should be a feature of the patch generating script in the gcc repo. No hand rolled patches.
   My feeling is that this will go away anyway the next time we update gcc though. 🤔

2. scripts directory

• The gcc script changes are related to the previous point, so they hinge on whether or not we take that route.
• binutils-SPU changes looks fine and can be squash-merged separately. I guess the equivalent changes to binutils-PPU (if still needed) will be handled by the separate binutils version bump PR?
• ps3libraries change looks OK, although I wonder why not do this in toolchain.sh instead so that it covers all build steps?

3. download.sh
   I may have some nits (need to go through it more carefully), but in general it looks fine and can be squash-merged separately.

[zeldin]

Using wc -c with a redirection from stdin forces wc to read the whole file to count the bytes. Better to use

wc -c "$1" | awk '{print $1}'

so that it can use use stat().

[humbertodias]

good idea. changed to use stat()

[zeldin]

Why? If a line is missing in archives.txt, shouldn't we just add it so that we get the SHA as well?

[humbertodias]

makes sense. i removed the guess_url() function

[humbertodias]

Thanks. Now we have something manageable to review. 😄

Will you make additional PR:s for the binutils bump and/or CI/docker changes?

Let's consider the three parts of what is left in this PR:

1. `patches` directory
   AFAICT this just amounts to splitting out the cherry-picked host fixes into separate patch files.
   I don't think we need to do this; it's not like we need to exclude the macos host fixes on non-macos systems, and it's pretty clear in the gcc repo what is what.
   However, if we _do_ want to do this, it should be a feature of the patch generating script in the gcc repo.  No hand rolled patches.
   My feeling is that this will go away anyway the next time we update gcc though.  🤔

2. `scripts` directory


* The gcc script changes are related to the previous point, so they hinge on whether or not we take that route.

* binutils-SPU changes looks fine and can be squash-merged separately.  I guess the equivalent changes to binutils-PPU (if still needed) will be handled by the separate binutils version bump PR?

* ps3libraries change looks OK, although I wonder why not do this in `toolchain.sh` instead so that it covers all build steps?


3. `download.sh`
   I may have some nits (need to go through it more carefully), but in general it looks fine and can be squash-merged separately.

#150
#151
#152
#153

[zeldin]

Awsome! Thanks.

[Fancy2209]

GDB was causing issues building on macOS from what I remember and users can install GDB-Multiarch to get the same result, we also have no way to actually use GDB outside RPCS3 from what I know. I can look into restoring it.

Sounds like a better solution would be to fix the build issues then. Probably there is some upstreams commit that can be backported.

GDB should be able to interact with gdbserver running on hardware I think.

Oh I see, my bad! Should I wait for humber to split his GCC Restoration or should I work on it?

[zeldin]

Oh I see, my bad! Should I wait for humber to split his GCC Restoration or should I work on it?

I actually started working on restoring GDB myself today. 😄

The macOS issue turned out to be with zlib, so I'm attempting to just add --with-system-zlib to the configure arguments and see how that pans out. If everything goes well I should be able to get it in tonight or tomorrow.

[Fancy2209]

I see nice! Again apologies for doing that, never pushing straight to main again, that's for sure.

[humbertodias]

already merged

[bucanero]

thanks @humbertodias for all the work across the gcc PRs, and @zeldin for restoring GDB 🙏