Re: [PATCH] MIPS: VDSO: Always select -msoft-float

[Maciej W. Rozycki]

On Sun, 30 Oct 2016, Guenter Roeck wrote:

> Some toolchains fail to build mips images with the following build error.
> 
> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'
> 
> This is seen, for example, with the 'mipsel-linux-gnu-gcc (Debian 6.1.1-9)
> 6.1.1 20160705' toolchain as used by the 0Day build robot when building
> decstation_defconfig.
> 
> Comparison of compile flags suggests that the major difference is a missing
> '-soft-float', which is otherwise defined unconditionally.
> 
> Reported-by: kbuild test robot <fengguang.wu@xxxxxxxxx>
> Cc: James Hogan <james.hogan@xxxxxxxxxx>
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> ---

 Using `-msoft-float' changes the floating-point ABI with the result being 
incompatible with the rest of the userland.  I think the dynamic loader 
may not be currently enforcing ABI compatibility here, but this may change 
in the future.

 Using `-mno-float' in place of `-msoft-float' might be a safer option, 
because even if we start enforcing floating-point ABI checks in dynamic 
loading, then `-mno-float' DSOs will surely remain compatible with 
everything else, because they guarantee no floating-point code or data 
even to be ever produced by the compiler, be it using the software or the 
hardware ABI.  One problem with that option is however that it is 
apparently not universally accepted, for reasons unclear to me offhand.

 That written not so long ago I actually explicitly tried the config file 
sent by the build bot reporting this issue and I built a kernel thus 
configured with current upstream top-of-tree toolchain components, which 
went just fine.  So what I suspect you've observied is just another sign 
of a bug which has been already fixed, maybe even the very same binutils 
bug I referred to recently.

 If you send me the generated assembly, i.e. `gettimeofday.s', that is 
causing you trouble, then I'll see if I can figure out what is going on 
here.  We may decide to paper a particularly nasty toolchain bug over from 
time to time rather than requesting users to apply the relevant proper fix 
to the toolchain, but before we do so I think we first need to thoroughly 
understand what the issue is so as not to cause more harm than good with 
the workaround.

  Maciej