Hi,
On 2021/3/19 上午9:38, YunQiang Su wrote:
Maciej W. Rozycki <macro@xxxxxxxxxxx> 于2021年3月18日周四 上午7:16写道：
On Mon, 15 Mar 2021, Thomas Bogendoerfer wrote:
In Golang, now we add the FP32 annotation, so the future golang programs
won't have this problem. While for the existing binaries, we need a
kernel workaround.
what about just rebuilding them ? They are broken, so why should we fix
broken user binaries with kernel hacks ?
I agree.
I went ahead and double-checked myself what the situation is here since I
could not have otherwise obtained the answer to the question I asked, and
indeed as I suspected even the simplest Go program will include a dynamic
libgo reference (`libgo.so.17' with the snapshot of GCC 11 I have built
for the MIPS target). So a userland workaround is as simple as relinking
this single library for the FP32 model. This will make the dynamic loader
force the FR=0 mode for all the executables that load the library.
In fact gccgo has no problem here at all.
The problem is about Google's golang: golang.org
Since as YunQiang says they're going to rebuild Golang with FP32
annotation anyway, which will naturally apply to the dynamic libgo library
as well, this will fix the problem with the existing binaries in the
current distribution. Given that this is actually a correct fix (another
one is required for the linker bug) I see no reason to clutter the kernel
with a hack. Especially as users will have to update a component anyway,
in this case the Go runtime rather than the kernel (which is better even,
as you don't have to reboot).
Normally Go has no runtime. For Debian, we patched golang-1.15, and all
go objects in Debian bullseye will be OK.
While, the objects in Debian buster or previous version or other distribution
may still broken.
The user may need to run these application on a kernel with O32_FP64
support enabled.
Yes, Ingenic X2000 processor has encountered this problem. In fact, all
MIPS32r5 and MIPS32r6 processors may encounter this problem (because
O32_FP64 is selected by default on MIPS32r5 and MIPS32r6), and we have
indeed encountered this when running docker on debian10, our solution is
similar to the current Yunqiang's method.
Thanks and best regards!
Once Golang has been modernised to use the FPXX mode the problem will go
away, and given the frequent version bumps in libgo's soname the current
breakage won't be an issue for whatever future version of Debian includes
it as the whole distribution will of course have been rebuilt against the
new library and any old broken executables kept by the user with a system
upgrade will continue using the old FP32 dynamic library.
Yes. As show on commit-msg, the patches for Golang have been accepted.
https://go-review.googlesource.com/c/go/+/239217
https://go-review.googlesource.com/c/go/+/237058
The bad news is that (Google's) Go has no runtime.
Currently, FR=1 mode is used for all FPXX binary, it makes some wrong
behivour of the binaries. Since FPXX binary can work with both FR=1 and FR=0,
we force it to use FR=0 or FRE (for R6 CPU).
I'm not sure, if I want to take this patch.
Maciej, what's your take on this ?
Given what I have written previously and especially above I maintain my
objection. I don't understand why we're supposed to do people's homework
though and solve their problems.
Maciej
