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
