Re: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Ivo De Decker <ivodd@debian.org> 于2021年2月9日周二 下午9:45写道：
>
> Hi,
>
> On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote:
> > 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
> > >
> > > 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.
> >
> > What is clear at this point is that the kernel change should be reverted
> > in buster since it causes a regression (including build failures on
> > buildds). I am cloning this bug for a revert in the kernel of
> > https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826
> >
> > I am marking the version in bullseye as found since we might run into
> > the same problem again when buster DSAs will be built on machines
> > running the bullseye kernel after the release of bullseye. It might be
> > possible to mitigate this problem (e.g. in the kernel or by keeping some
> > buildd running with the buster kernel), but without an open bug this
> > issue might get forgotten and then resurface after the bullseye release.
>
> Could the mips porters comment on this? Given that we're close to the release
> of bullseye, I'm not convinced it's a good idea to change this now.
Yes. It will be a problem to run with buster's golang program on
bullseys's kernel.
Let's have another way to get this problem sloved without revert this changes.
Maybe detect the golang applications and run them in FP32 mode?
>
> Cheers,
>
> Ivo
>
>
Reply to: