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