On Tue, Nov 01, 2016 at 10:40:24PM +0000, Maciej W. Rozycki wrote:
> 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
The problem is seen in 0Day builds, with the toolchain mentioned above.
I don't see the problem myself; I used to see it but switched toolchains
instead of trying to nail down the problem.
I don't think that generated assembly is going to help, though, since the
compiler fails to compile the code in the first place because, as it says,
it doesn't like '-march=r3000' without '-mfp32'.
Guenter
