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. 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). 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. > > 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
