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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

 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.

 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.

  Maciej



[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux