Move binutils, GDB, and GCC to the upstream repos

[palmer-dabbelt]

I bumped these pointers to the same master/trunk-based commits that I'd tested last time, but haven't re-run the tests after the GCC bump. I'll do that, and I was seeing a bunch of failures with only the binutils bump so I was a bit worried.

[cmuellner]

Was the switch from https to git as protocol intended?
I think the use of https was on purpose (see e.g. #1063).

In general, I think moving to upstream/master is a great improvement.
Users will get the latest upstream features, and upstream will get more test exposure.

[kito-cheng]

hmmm, it's hard decision to me, that's double edged sword, I know it's helper to improve the stability of trunk since there would be more user to use/testing that, and we don't need to spend time to backport patches.

However using trunk means that might unstable, and not everyone is experienced can identify that's toolchain's bug or their own bug, and the target user of this repo (in my mind) is RISC-V newbies, so I am little hesitate here.

But I must say I didn't have too much bandwidth to maintain both upstream and here for a while...so maybe that's best way to go.

[cmuellner]

There is still a pinning to a defined upstream commit in place.
So it is up to the person who does the merge to accept the version bump.
If we take care to only merge changes to commits around stable versions and require an update of the test suite like in this PR,
then the risk of unnecessary regressions should be low. And those regressions that are found need to be addressed upstream anyway.

[jim-wilson]

Some people use riscv-gnu-toolchain to make toolchain releases. Using upstream trunk for a release will get you a lot of hate mail from FSF developers. This will be a serious problem if it happens, and could damage the reputation of all RISC-V toolchain developers. This is why we specifically use release branches instead of trunk. If we are going to switch, we need to make it absolutely clear that riscv-gnu-toolchain can no longer be used to make toolchain releases. And we will need to enforce this somehow or we will be screwed.

A lot of newbies use riscv-gnu-toolchain. A newbie should not be forced to use trunk which will be much less stable than a release branch.

We have gdb patches for the simulator which are not upstream yet. I tried last year, ended up with a ~20 part series of patches, and got so many review requests to modify the patches that I had to defer it to later, and haven't gotten back to it yet. Anyways, if we switch from our local gdb to upstream gdb we lose our gdb sim support. The upstream one is badly broken, and missing even some basic extensions. I should probably fix that, but I haven't gotten bored enough to return to RISC-V toolchain work yet. I will miss the gdb sim support, and I think that Kito will miss it, but I don't know if anyone else will miss it. Anyways, not a fatal problem.

If you really want to switch to trunk, then we probably need to provide two versions, one based on branches for releases and newbies which is the one people get by default, and one based on trunk for developers that has to be specially requested e.g. by checking out a branch. That will affect the maintenance workload, but should be manageable if I return to doing RISC-V toolchain work.

I use upstream trunk with riscv-gnu-toolchain, but I do it by hand. I use git remote to add the FSF repo, git fetch it, and then switch to an FSF branch. I do that in binutils and gcc which are the ones I care most about. Then I leave it on my disk and use it for years with the occasional update to get new versions of riscv-gnu-toolchain, binutils, and gcc. If you are building natively, you don't need riscv-gnu-toolchain at all. I just build and install binutils and gdb, then build and install gcc, then build but not install glibc. I can test all 4 natively pretty easily. It is slower than cross testing, but more useful than cross testing for linux support.

[palmer-dabbelt]

Some people use riscv-gnu-toolchain to make toolchain releases. Using upstream trunk for a release will get you a lot of hate mail from FSF developers. This will be a serious problem if it happens, and could damage the reputation of all RISC-V toolchain developers. This is why we specifically use release branches instead of trunk. If we are going to switch, we need to make it absolutely clear that riscv-gnu-toolchain can no longer be used to make toolchain releases. And we will need to enforce this somehow or we will be screwed.

Makes sense, though I'm not really sure how it's possible to do that. If it's that big of a deal I can just stick to trunk locally, that's what I do already (and from below sounds like what you do too).

A lot of newbies use riscv-gnu-toolchain. A newbie should not be forced to use trunk which will be much less stable than a release branch.

I'd argue newbies shouldn't be building toolchains at all, but I guess that's a different problem.

We have gdb patches for the simulator which are not upstream yet. I tried last year, ended up with a ~20 part series of patches, and got so many review requests to modify the patches that I had to defer it to later, and haven't gotten back to it yet. Anyways, if we switch from our local gdb to upstream gdb we lose our gdb sim support. The upstream one is badly broken, and missing even some basic extensions. I should probably fix that, but I haven't gotten bored enough to return to RISC-V toolchain work yet. I will miss the gdb sim support, and I think that Kito will miss it, but I don't know if anyone else will miss it. Anyways, not a fatal problem.

Still a headache, though, and I think there's some sim users around. I can try and find someone else to pick up the sim stuff if you want, we've got a lot of new folks around who are learning RISC-V and this sort of this is a good way to get someone started.

If you really want to switch to trunk, then we probably need to provide two versions, one based on branches for releases and newbies which is the one people get by default, and one based on trunk for developers that has to be specially requested e.g. by checking out a branch. That will affect the maintenance workload, but should be manageable if I return to doing RISC-V toolchain work.

I've already got a fork that points to trunk, so no big deal on my end (it's actually easier if I don't have to send PRs here). My plan was to get all the allowlist stuff upstream anyway, but I figured adding them here was sanest so everyone could see what's up.

I use upstream trunk with riscv-gnu-toolchain, but I do it by hand. I use git remote to add the FSF repo, git fetch it, and then switch to an FSF branch. I do that in binutils and gcc which are the ones I care most about. Then I leave it on my disk and use it for years with the occasional update to get new versions of riscv-gnu-toolchain, binutils, and gcc. If you are building natively, you don't need riscv-gnu-toolchain at all. I just build and install binutils and gdb, then build and install gcc, then build but not install glibc. I can test all 4 natively pretty easily. It is slower than cross testing, but more useful than cross testing for linux support.

[kito-cheng]

I'd argue newbies shouldn't be building toolchains at all, but I guess that's a different problem.

Actually there is many post around the web are using riscv-gnu-toolchain as part of tutorial, especially on the Chinese community, so no matter it's make sense or not...it's fact :(

---

An alternative is maintain two branches on master branch of riscv-gnu-toolchain and using some configuration option to switch that, e.g. --with-release=[12|trunk]? but that require did some

[palmer-dabbelt]

I'd argue newbies shouldn't be building toolchains at all, but I guess that's a different problem.

Actually there is many post around the web are using riscv-gnu-toolchain as part of tutorial, especially on the Chinese community, so no matter it's make sense or not...it's fact :(

Yep, sounds like there's nothing we can do about it.

An alternative is maintain two branches on master branch of riscv-gnu-toolchain and using some configuration option to switch that, e.g. --with-release=[12|trunk]? but that require did some

That seems way more complicated than it's worth, it's not like there's any meaningful tracking of submodule merges anyway so I don't mind just maintaining the fork. We should really get all those test failures fixed upstream either way, so at that point it'll just be submodule juggling and that's pretty trivial.

[cmuellner]

I'd like us all to reconsider this PR (i.e. going to upstream sources).

I fully understand that people depend on this repo for building their toolchains,
but there was no other PR than this here for bumping GCC for 14 months.

So the choice is not stable releases or upstream, but outdated releases or upstream
(unless somebody steps up and volunteers to maintain another strategy).

[pz9115]

Maybe we can monthly or quarterly to update this repo's main branch, it will reduce the difference from upstream,
and provide more new features support on RISC-V target. The update can be determined by RISC-V progress,
not by upstream progress.

Still keep some stable release version branch（yearly update follows gcc10, 11, 12 ...）
to make users build and use more friendly.

[fwsGonzo]

This PR is the only one that really works for me with shallow submodules. For some reason master branch is just not checking out binutils submodule properly.

[cmuellner]

I'm going to close this issue unmerged, as the spirit of this PR has been merged in other recent PRs:

• Submodules for Binutils, GDB, GCC, and dejagnu reference upstream git repos
• Binutils, GDB, GCC, and dejagnu reference the latest upstream release versions
• allowlists have been updated

Additionally, the following riscv repos have been archived:

• riscv-binutils-gdb
• riscv-dejagnu
• riscv-newlib
• riscv-lld

riscv-gcc remains active as it is used for GCC RVV-enablement development.

Thanks for triggering these changes!