> On Wed, 3 Mar 2021, yunqiang.su@xxxxxxxxxxxxx wrote: > > > > > v5->v6: > > > > Rollback to V3, aka remove config option. > > > > > > You can't reuse v3 as it stands because it breaks R6 as we > > > previously discussed. You need to tell R6 and earlier ISAs apart > > > and set the FR bit accordingly. > > > > > > > It won't break r6, as all of r6 binary is FP64, and on r6 > > `frdefault' is always false, and `fr1' is always true. > > It won't trigger this mode switch. > > > > Oh, you are right, there may be a case that to run legacy app on r6 CPU. > > For this case, on r6, we need to set the CPU to FRE mode. > > The FRE mode causes a severe performance regression for single FP > operations, so we shouldn't use it for FPXX software. > If we need to run pre-R6 FPXX/FP32 app on r6 CPU, it may be the only choice for us. Any way, in this case we need lots of T&E, the problem of FRE won't be a big problem. > As a matter of interest: do you have figures available as to how many > software packages are affected in Debian? > Almost all packages built with Golang in buster. > Also it has now struck me that another userland workaround should be > possible, by setting LD_PRELOAD in the environment system-wide to a > dummy FR=0 DSO (e.g. via /etc/environment or /etc/initscript; I reckon > systemd has its own way too), which will force the right mode the normal way. > All the distribution has been built for FPXX I presume, right? > It is not acceptable for "stable" branch of distributions. For developing branch, we have fixed this problem on Golang itself. > You can distribute a package with the dummy along with the environment > entry to all the people who require it. I fail to see how it could be more > problematic than getting a questionable hack included in the kernel forever > and then requiring everyone to upgrade the relevant packages anyway, which > you will have to supply for stable releases too. > So, I'd prefer to introduce a new CONFIG option. > Or I guess you could just rebuild libc as FR=0 instead, or is there a Golang > standard library that every Golang program uses? And then have people > upgrade that package instead. > Rebuiding libc to FP32 is not acceptable, since we want to do is to support MSA, Which require FR=1 and all the result is FP64. In fact we found this problem when we try to enable MIPS_O32_FP64_SUPPORT, Without this option is enabled, all FPXX binaries are still use FR=0 mode: See: function mips_set_personality_fp() So, here, we doesn't introduce the rollback to FR=0. > It seems to me like there are still a couple of alternatives available. > You might be able to come up with yet more if you continued looking for them. > I consider putting any workaround into the kernel the last resort really. The > problem is in the userland, so let's try hard to deal with it there. > Yes. It is problem of userland, while it has no way to fix in for the pre-exist binaries in userland. > Maciej
