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