Re: Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel
On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote:
> On 2020-05-28 09:04, YunQiang Su wrote:
> > Adrian Bunk <bunk@debian.org> 于2020年5月21日周四 下午3:40写道：
> > >
> > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote:
> > > > Adrian Bunk <bunk@debian.org> 于2020年5月21日周四 上午4:44写道：
> > > > >
> > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> > > > > >
> > > > > > FTR, after giving back golang-1.14 mipsel several times, it's finally
> > > > > > built, by a longson builder.
> > > > > > So I guess it only occurs on octeon. Since the porterbox eller is also
> > > > > > octeon, it also can't build any go program.
> > > > >
> > > > > On eller golang-1.14 fails to build both in sid and buster chroots.
> > > > >
> > > > > golang-1.11 also fails to build in a buster chroot with floating point
> > > > > test errors.
> > > > >
> > > > > golang-1.14 gets unbroken by GOMIPS=softfloat.
> > > > >
> > > > > The only kernel configuration change on eller in the buster point
> > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would
> > > > > make sense if the problem is that golang-1.11 and golang-1.14 are
> > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.
> > > >
> > > > It is just support O32_FP64. I don't expect it will have any effect.
> > > > Since currently, the toolchain/libraries are all FPXX.
> > >
> > > Only the gcc/binutils toolchain/libraries or also the Go toolchain?
> >
> > you are right. the current golang still output FP32 object...
> > So, we think that it is buggy.
> >
> > Since Loongson CPU has some strange behaviour, it even can work...
> > Let's try to patch golang to support FPXX or FP64.
> >
> > https://github.com/golang/go/issues/39289
The amount of compilers and JITs in Debian makes me worry there might
be more such problems.
> That's probably a solution for bullseye/sid, however we can't backport
> such changes and rebuild the go world in buster. I therefore think that
> for buster the kernel change has to be reverted.
Even bullseye sounds one release too early to me.
People will be running bullseye with the buster kernel during the upgrade.
How will security updates for buster be built when the buildds will be
running the bullseye kernel?
> Aurelien
cu
Adrian
Reply to: