回复: 回复: [PATCH v6] MIPS: force use FR=0 for FPXX binary

[<yunqiang.su@cipunited.com>]

> On Wed, 3 Mar 2021, yunqiang.su@cipunited.com 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