Maciej W. Rozycki <macro@xxxxxxxxxxx> 于2021年2月28日周日 下午9:39写道： > > On Sun, 28 Feb 2021, yunqiang.su@xxxxxxxxxxxxx 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
