Re: 回复: [PATCH v4] MIPS: introduce config option to force use FR=0 for FPXX binary

[YunQiang Su <wzssyqa@gmail.com>]

Maciej W. Rozycki <macro@orcam.me.uk> 于2021年2月28日周日 下午9:39写道：
>
> On Sun, 28 Feb 2021, yunqiang.su@cipunited.com wrote:
>
> > >  This is also the correct interpretation for objects produced by Golang, which I
> > > have concluded are actually just fine according to the traditional psABI
> > > definition.  It looks to me like the bug is solely in the linker, due to this weird
> > > interpretation quoted above and unforeseen consequences for FPXX links
> > > invented much later.
> > >
> >
> > Yes. This a bug of linker, and we should fix it.
> > While for pre-existing binaries, we need a solution to make it workable, especially for the
> > generic Linux distributions, just like Debian.
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962485
>
>  Thanks for the pointer.
>
>  After a bit of thinking and having fully understood what the issue
> actually is I conclude a change like your original one (with no
> configuration option; we've got too many of them already) will be OK so
> long as it keeps the current arrangement for R6, which has the FR mode
> hardwired, because, as you say, for genuine FPXX binaries the actual FR
> setting does not matter, so the change in the fixed form won't break what
> hasn't been broken already.
>
>  Please keep the history of changes in the comment section rather that the
> change description though.  Also I think the change description needs to
> be more elaborate on the motivation, so that someone who looks at it say
> 10 years from now can figure out what is going on here.  You can reuse
> bits of our discussion for that purpose.
>
>  Sadly I can see many changes going in where the description hardly says
> anything, and while the matter may seem obvious right now, it surely won't
> be for someone trying to unbreak things years from now while keeping the
> intent of the original change where it did the right thing.  Especially as
> secondary sources of information may not be easily available (anymore) and
> the test environment may not be easily reproducible.  Notice how often I
> need to refer to changes that were made many years ago and were not always
> correct.
>
>  NB the real problem are not programs included with the distribution
> (which as I say can and ought to be fixed up with a script automatically;
> a distribution needs to have provisions for such workarounds as problems
> with the toolchain inevitably do happen from time to time), but programs
> built by users of the distribution who we cannot reasonably expect to be
> aware of every single quirk out there.
>

The "stable" branch of distribution is in the same situation as the user.
Normally, we cannot modify the binary in the "stable" branch.

>  Observe however that this does not solve the issue of a link-time or
> load-time incompatibility between FP32 modules incorrectly marked FPXX and
> FP64 or FP64A modules.  These will be let through and depending on usage
> likely eventually fail.
>

Yes, that's a problem. the patch of golang has been merged now.
https://go-review.googlesource.com/c/go/+/239217
https://go-review.googlesource.com/c/go/+/237058
And we will continue to try to fix binutils/llvm etc.

>  You might be able to come up with a wrapper script in place of whatever
> the Golang invocation command is to postprocess modules produced in user
> compilations as well, and have it distributed until the linker issue has
> been fixed upstream and the changes propagated back to the distribution.
>

We fixed the golang itself, and the packages has been in Debian bullseye now.

>   Maciej



-- 
YunQiang Su