Maciej W. Rozycki [off-list ref] 于2021年2月28日周日 下午9:39写道：

On Sun, 28 Feb 2021, yunqiang.su@cipunited.com wrote:

quoted

quoted

 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