mbox series

[bug#49019,0/1] gnu: Add gccgo-10.

Message ID 20210614041653.3085-1-iskarian@mgsn.dev
Headers show
Series gnu: Add gccgo-10. | expand

Message

Sarah Morgensen June 14, 2021, 4:16 a.m. UTC
The primary goal for adding gccgo is to bootstrap the go compiler for arches
that aren't supported by go 1.4. I believe the major one to support here is
powerpc64le, but I am unsure of current arch usage. A secondary goal is to
provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.

I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
gcc 10 using `make check-go`. There are two minor test failures:

1. index0-out.go, previously reported upstream [0]
2. pprof (TestConvertCPUProfile/TestConvertMemProfile)

(I have not yet been able to deterine whether the pprof failures are an upstream
bug or a Guix bug. Should I send details to bug-guix?)

Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
should be removed after the change is in master.

[0] https://issues.guix.gnu.org/49010
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589

Sarah Morgensen (1):
  gnu: Add gccgo-10.

 gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

Comments

Efraim Flashner June 21, 2021, 1:25 p.m. UTC | #1
On Sun, Jun 13, 2021 at 09:16:53PM -0700, Sarah Morgensen via Guix-patches via wrote:
> The primary goal for adding gccgo is to bootstrap the go compiler for arches
> that aren't supported by go 1.4. I believe the major one to support here is
> powerpc64le, but I am unsure of current arch usage. A secondary goal is to
> provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.
> 
> I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
> gcc 10 using `make check-go`. There are two minor test failures:
> 
> 1. index0-out.go, previously reported upstream [0]
> 2. pprof (TestConvertCPUProfile/TestConvertMemProfile)
> 
> (I have not yet been able to deterine whether the pprof failures are an upstream
> bug or a Guix bug. Should I send details to bug-guix?)

I wouldn't worry about the test failures.

> Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
> CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
> should be removed after the change is in master.

Makes sense

> [0] https://issues.guix.gnu.org/49010
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
> 
> Sarah Morgensen (1):
>   gnu: Add gccgo-10.
> 
>  gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
> 
> -- 
> 2.31.1
> 

I threw together a quick gccgo-toolchain package and tried using that to
build keybase and syncthing. One of the errors I came across was:
/home/efraim/go/pkg/mod/golang.org/x/sys@v0.0.0-20200922070232-aee5d888a860/unix/gccgo.go:50:
undefined reference to `gccgoRealSyscallNoError' and also
github.com/minio/sha256-simd@v0.1.1 didn't like the assembly in the
package.

It's definitely possible that I'm missing some flag to tell go that I'm
really using gccgo. Or that it should be built with binutils-gold.
vasilii.smirnov--- via Guix-patches" via June 21, 2021, 9:32 p.m. UTC | #2
Thanks for taking a look at this, Efraim!

June 21, 2021 6:25 AM, "Efraim Flashner" <efraim@flashner.co.il> wrote:

> On Sun, Jun 13, 2021 at 09:16:53PM -0700, Sarah Morgensen via Guix-patches via wrote:
> 
>> The primary goal for adding gccgo is to bootstrap the go compiler for arches
>> that aren't supported by go 1.4. I believe the major one to support here is
>> powerpc64le, but I am unsure of current arch usage. A secondary goal is to
>> provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.
>> 
>> I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
>> gcc 10 using `make check-go`. There are two minor test failures:
>> 
>> 1. index0-out.go, previously reported upstream [0]
>> 2. pprof (TestConvertCPUProfile/TestConvertMemProfile)
>> 
>> (I have not yet been able to deterine whether the pprof failures are an upstream
>> bug or a Guix bug. Should I send details to bug-guix?)
> 
> I wouldn't worry about the test failures.
> 
>> Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
>> CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
>> should be removed after the change is in master.
> 
> Makes sense
> 
>> [0] https://issues.guix.gnu.org/49010
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
>> 
>> Sarah Morgensen (1):
>> gnu: Add gccgo-10.
>> 
>> gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 77 insertions(+)
>> 
>> --
>> 2.31.1
> 
> I threw together a quick gccgo-toolchain package and tried using that to
> build keybase and syncthing. One of the errors I came across was:
> /home/efraim/go/pkg/mod/golang.org/x/sys@v0.0.0-20200922070232-aee5d888a860/unix/gccgo.go:50:
> undefined reference to `gccgoRealSyscallNoError' and also
> github.com/minio/sha256-simd@v0.1.1 didn't like the assembly in the
> package.

The assembly problem is (unfortunately) a known limitation of gccgo. The gc and
gccgo compilers use different asm syntax, so many extant go programs cannot
currently be compiled with gccgo alone. There are also other limitations with
the go tools provided by gccgo, as only a subset have been implemented.

However, I have successfully built go-1.16 with gccgo with a few tweaks. (Most
dependent packages build with no modification or with a version bump, and I
have minimal patches for the handful of others. Docker will have to be updated
to work with go-1.16, which will likely be out of my depth.) I plan to share
a patchset for this soon.

As for x/sys: most likely updating the module dependency will solve it. I see
x/sys has had some gccgo related commits since that version was released.

> It's definitely possible that I'm missing some flag to tell go that I'm
> really using gccgo. Or that it should be built with binutils-gold.

I must admit that I had not even thought about whether gold might be
necessary. I really am out of my depth on this one. I see that you authored
the patch for go@1.14 to use gold on armhf and aarch64, so you likely know
more about this than me! Presumably that was in regards to [0] and [1]?

Other than that, the main motivation for using gold seems to be the support for
split-stack, which allows the use of many more goroutines before running out of
stack space [2]. Replacing GNU ld (`./configure --with-ld=...') as [2] suggests
may introduce bugs... It appears that in at least one case (ppc64) gccgo
prefers gold even if gcc was not built solely with it [3]. Unfortunately, adding
gold as an optional linker would add ~75MiB to closure size...

I'm not sure what the best way forward is, here. WDYT?

> --
> Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

[0]: https://github.com/golang/go/issues/15696
[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=19962
[2]: https://golang.org/doc/install/gccgo#Gold
[3]: https://github.com/gcc-mirror/gcc/commit/402565b61f9783473472fcfd729efa8c1e355d2b
Efraim Flashner June 28, 2021, 7:22 p.m. UTC | #3
On Mon, Jun 21, 2021 at 09:32:22PM +0000, iskarian@mgsn.dev wrote:
> Thanks for taking a look at this, Efraim!
> 
> June 21, 2021 6:25 AM, "Efraim Flashner" <efraim@flashner.co.il> wrote:
> 
> > On Sun, Jun 13, 2021 at 09:16:53PM -0700, Sarah Morgensen via Guix-patches via wrote:
> > 
> >> The primary goal for adding gccgo is to bootstrap the go compiler for arches
> >> that aren't supported by go 1.4. I believe the major one to support here is
> >> powerpc64le, but I am unsure of current arch usage. A secondary goal is to
> >> provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.
> >> 
> >> I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
> >> gcc 10 using `make check-go`. There are two minor test failures:
> >> 
> >> 1. index0-out.go, previously reported upstream [0]
> >> 2. pprof (TestConvertCPUProfile/TestConvertMemProfile)
> >> 
> >> (I have not yet been able to deterine whether the pprof failures are an upstream
> >> bug or a Guix bug. Should I send details to bug-guix?)
> > 
> > I wouldn't worry about the test failures.
> > 
> >> Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
> >> CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
> >> should be removed after the change is in master.
> > 
> > Makes sense
> > 
> >> [0] https://issues.guix.gnu.org/49010
> >> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
> >> 
> >> Sarah Morgensen (1):
> >> gnu: Add gccgo-10.
> >> 
> >> gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 77 insertions(+)
> >> 
> >> --
> >> 2.31.1
> > 
> > I threw together a quick gccgo-toolchain package and tried using that to
> > build keybase and syncthing. One of the errors I came across was:
> > /home/efraim/go/pkg/mod/golang.org/x/sys@v0.0.0-20200922070232-aee5d888a860/unix/gccgo.go:50:
> > undefined reference to `gccgoRealSyscallNoError' and also
> > github.com/minio/sha256-simd@v0.1.1 didn't like the assembly in the
> > package.
> 
> The assembly problem is (unfortunately) a known limitation of gccgo. The gc and
> gccgo compilers use different asm syntax, so many extant go programs cannot
> currently be compiled with gccgo alone. There are also other limitations with
> the go tools provided by gccgo, as only a subset have been implemented.
> 
> However, I have successfully built go-1.16 with gccgo with a few tweaks. (Most
> dependent packages build with no modification or with a version bump, and I
> have minimal patches for the handful of others. Docker will have to be updated
> to work with go-1.16, which will likely be out of my depth.) I plan to share
> a patchset for this soon.
> 
> As for x/sys: most likely updating the module dependency will solve it. I see
> x/sys has had some gccgo related commits since that version was released.

Sounds good.

> > It's definitely possible that I'm missing some flag to tell go that I'm
> > really using gccgo. Or that it should be built with binutils-gold.
> 
> I must admit that I had not even thought about whether gold might be
> necessary. I really am out of my depth on this one. I see that you authored
> the patch for go@1.14 to use gold on armhf and aarch64, so you likely know
> more about this than me! Presumably that was in regards to [0] and [1]?

That one's come forward with a couple of go versions. Perhaps it'd be
best to add it unconditionally, or at least to switch the logic and only
skip it on x86_64 and i686.

> Other than that, the main motivation for using gold seems to be the support for
> split-stack, which allows the use of many more goroutines before running out of
> stack space [2]. Replacing GNU ld (`./configure --with-ld=...') as [2] suggests
> may introduce bugs... It appears that in at least one case (ppc64) gccgo
> prefers gold even if gcc was not built solely with it [3]. Unfortunately, adding
> gold as an optional linker would add ~75MiB to closure size...
> 
> I'm not sure what the best way forward is, here. WDYT?

It's not a lot of extra closure size, given just how large the go
package itself is. I think we leave it as-is for now and add change it
up later if necessary.

> 
> [0]: https://github.com/golang/go/issues/15696
> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=19962
> [2]: https://golang.org/doc/install/gccgo#Gold
> [3]: https://github.com/gcc-mirror/gcc/commit/402565b61f9783473472fcfd729efa8c1e355d2b