> -----邮件原件----- > 发件人: Maciej W. Rozycki <macro@xxxxxxxxxxx> > 发送时间: 2021年2月28日 9:48 > 收件人: YunQiang Su <wzssyqa@xxxxxxxxx> > 抄送: YunQiang Su <yunqiang.su@xxxxxxxxxxxxx>; Thomas Bogendoerfer > <tsbogend@xxxxxxxxxxxxxxxx>; Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx>; > linux-mips <linux-mips@xxxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx > 主题: Re: [PATCH v4] MIPS: introduce config option to force use FR=0 for FPXX > binary > > On Tue, 23 Feb 2021, YunQiang Su wrote: > > > YunQiang Su <yunqiang.su@xxxxxxxxxxxxx> 于2021年2月22日周一 上 > 午11:45写道： > > > > > > some binary, for example the output of golang, may be mark as FPXX, > > > while in fact they are still FP32. > > > > > > Since FPXX binary can work with both FR=1 and FR=0, we introduce a > > > config option CONFIG_MIPS_O32_FPXX_USE_FR0 to force it to use FR=0 > here. > > > > As the diffination, .gnu.attribution 4,0 is the same as no > > .gnu.attribution section. > > Its meaning is that the binary has no float operation at all. > > Nope, quoting include/elf/mips.h from GNU binutils: > > /* Not tagged or not using any ABIs affected by the differences. */ > Val_GNU_MIPS_ABI_FP_ANY = 0, > > which means that the object file *either* does not use FP *or* has not been > tagged at all, as the GNU linker does not tell these two cases apart internally > (yes, quite useless semantics, but there you go; I think the enumeration > constant of 0 shouldn't have been chosen for any explicit tag, or possibly for > double float instead, so this is an ABI design mistake). > > Any object produced before mid 2007, specifically this GNU binutils > commit: > > commit 2cf19d5cb991a88bdc71d0852de8206d9510678f > Author: Joseph Myers <joseph@xxxxxxxxxxxxxxxx> > Date: Fri Jun 29 16:41:32 2007 +0000 > > will not have been tagged for FP use and therefore the traditional MIPS/Linux > psABI of double float has to be assumed. > > 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 > Yes, the two cases (not tagged vs tagged as 0) ought to be told apart and I > outlined a solution (needed for different reasons, but with the same > motivation) for the GNU linker in the course of the discussion around NaN > interlinking design, but that has never materialised before I effectively left the > MIPS world, only remaining active in a limited manner for legacy MIPS > platforms (that is ISAs I-IV). > > Maciej
