Thread (7 messages) 7 messages, 3 authors, 2021-03-03

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

From: <hidden>
Date: 2021-02-28 07:42:56
Also in: linux-mips

-----邮件原件-----
发件人: Maciej W. Rozycki [off-list ref]
发送时间: 2021年2月28日 9:48
收件人: YunQiang Su [off-list ref]
抄送: YunQiang Su [off-list ref]; Thomas Bogendoerfer
[off-list ref]; Jiaxun Yang [off-list ref];
linux-mips [off-list ref]; stable@vger.kernel.org
主题: Re: [PATCH v4] MIPS: introduce config option to force use FR=0 for FPXX
binary

On Tue, 23 Feb 2021, YunQiang Su wrote:
quoted
YunQiang Su [off-list ref] 于2021年2月22日周一 上
午11:45写道:
quoted
quoted
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.
quoted
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 [off-list ref]
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
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help