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

[Guenter Roeck]

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 
Cc: James Hogan 
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Signed-off-by: Guenter Roeck 
---
 arch/mips/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index c3dc12a8b7d9..9bdd6641400f 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -6,7 +6,8 @@ ccflags-vdso := \
$(filter -I%,$(KBUILD_CFLAGS)) \
$(filter -E%,$(KBUILD_CFLAGS)) \
$(filter -mmicromips,$(KBUILD_CFLAGS)) \
-   $(filter -march=%,$(KBUILD_CFLAGS))
+   $(filter -march=%,$(KBUILD_CFLAGS)) \
+   -msoft-float
 cflags-vdso := $(ccflags-vdso) \
$(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \
-O2 -g -fPIC -fno-strict-aliasing -fno-common -fno-builtin -G 0 \
-- 
2.5.0

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

[Maciej W. Rozycki]

On Fri, 4 Nov 2016, Matthew Fortune wrote:

> > > 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'.
> > 
> >  Indeed I got that confused, even though there is supposed to be a
> > mention in the compiler's diagnostics if a warning or error has
> > originated from an external tool invoked.  Sorry about that.  The
> > message itself could well have come from the assembler though as the
> > same options are accepted by that tool.
> > 
> >  And indeed I have just guessed what the cause might be, that is the
> > compiler must have been configured with an explicit `--with-fp-32=xx' or
> > `--with-fp-32=64' option.
> 
> This is almost certainly using --with-fp-32=xx

 Thanks for reconfirming.

> >  Here's quite an extensive analysis of what these options do and why:
> >  > _FR0_and_FR1_Interlinking>
> > and I note that there is a mention of a setup which would have avoided
> > the situation we have now:
> > 
> > "Ideally any MIPS I arch/core will default to -mfp32 Any MIPS II ->
> > MIPS32r2 arch/core will default to -mfpxx. However, this should be
> > controlled via a configure time option to adjust the default ABI from
> > O32
> > FP32 to O32 FPXX (or O32 FP64 as needed). The new configure time option
> > is --with-fp-32=[32|xx|64] and this affects the FP mode only when
> > targetting the O32 ABI."
> > 
> > however this ideal arrangement, which I would expect a configuration
> > option like `--with-fp-32=from-isa' (and a corresponding `-mfp=from-isa'
> > compiler option) would handle, got lost/forgotten in the works somehow.
> 
> The intention of these comments was about vendor tool configurations that
> often do more option inference than standard tools. We could do a
> --with-fp-32=from-isa but that would not be used by debian anyway as it
> does not meet the goal of reliably generating FP compatible code. There are
> also subjective answers to the 'from-isa' question as mips32r1 could be
> fp32 or fpxx depending on what the toolchain owner wanted to achieve.

 Why?

 With the use of `--with-fp-32=xx' the lone effect is a requirement for 
`-march=mips1' (or an equivalent CPU setting) compilations to pass an 
explicit `-mfp32' option or otherwise they fail.  Likewise you need to 
pass `-mfp64' for `-march=mips32r6' compilations.

 The effect on `-march=mips32' is I think irrelevant because it can just 
use `-mfpxx' as being MIPS II compatible the ISA does support LDC1/SDC1 
instructions unconditionally, even though the FPU implementation option is 
limited to 32 bits (not that any MIPS32r1 FPU hardware exist anyway 
AFAIK).  So we can just document the intent for `from-isa' to be maximum 
flexibility (link/load-time compatibility) and explicitly state that for 
`-march=mips32' `from-isa' means `xx'.

 By having `--with-fp-32=from-isa' you'd keep the current `-mfpxx' default 
for the currently working ISAs whereas those which now fail to build would 
not require the user to stick extra options which are implied by the ISA 
constraints anyway.  So you'd have a consistent compatible code unless the 
ISA contradicts it.

 Debian should not care as it's supposed to build all the packages using 
the same `-march=' setting (be it an ISA or CPU); presumably also wired as 
the default by using `--with-arch=' or `--with-arch-32='/`--with-arch-64=' 
as applicable.  Unless there's a packaging error that is, but I don't 
think checking for such a situation should be addressed in the compiler 
which is a generic tool.

> >  Matthew has been the expert in this area and might be able to add some
> > more -- Matthew?  Also shall we call it a compiler defect?  We seem to
> > be getting more and more toolchain configurations which break the
> > existing setups in a way requiring them to add more and more compiler
> > options to Makefiles for preexisting targets even though the Makefiles
> > were previously already prepared to choose the right compiler options
> > for the target.  This seems the wrong way to go to me as it's causing
> > people burden when upgrading their toolchains while it's supposed to be
> > seamless (it's one aspect of maintaining backwards compatibility).
> 
> I agree we don't want to take decisions lightly that end up breaking
> builds but we should not shy away from them.
> 
> In this specific case a kernel for a MIPS I arch is being built from a
> toolchain in a distribution that requires MIPS II as a minimum and is
> moving towards requiring MIPS32R2 as a minimum. The decisions made when
> configuring this toolchain are there to support the intended users so
> as we move forward there will be some things that stop working as
> before (by default).

 The Linux kernel has always been considered a special compilation case, 
starting from that you use a hosted compiler configuration to build a 
freesta

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 
> Cc: James Hogan 
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Signed-off-by: Guenter Roeck 
> ---

 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

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

[Guenter Roeck]

On Tue, Nov 01, 2016 at 10:40:24PM +, 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 
> > Cc: James Hogan 
> > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > Signed-off-by: Guenter Roeck 
> > ---
> 
>  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

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

[Maciej W. Rozycki]

On Tue, 1 Nov 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 
> > > Cc: James Hogan 
> > > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > > Signed-off-by: Guenter Roeck 
> > > ---
[...]
> >  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.

 That does not tell me anything -- I have no idea how each of the 
toolchains out there has been configured.  I can only assess information
provided by the bug/patch submitter, and otherwise try guessing.

> 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'.

 Indeed I got that confused, even though there is supposed to be a mention 
in the compiler's diagnostics if a warning or error has originated from an 
external tool invoked.  Sorry about that.  The message itself could well 
have come from the assembler though as the same options are accepted by 
that tool.

 And indeed I have just guessed what the cause might be, that is the 
compiler must have been configured with an explicit `--with-fp-32=xx' or 
`--with-fp-32=64' option.

 Here's quite an extensive analysis of what these options do and why: 

and I note that there is a mention of a setup which would have avoided the 
situation we have now:

"Ideally any MIPS I arch/core will default to -mfp32 Any MIPS II -> 
MIPS32r2 arch/core will default to -mfpxx. However, this should be 
controlled via a configure time option to adjust the default ABI from O32 
FP32 to O32 FPXX (or O32 FP64 as needed). The new configure time option is 
--with-fp-32=[32|xx|64] and this affects the FP mode only when targetting 
the O32 ABI."

however this ideal arrangement, which I would expect a configuration 
option like `--with-fp-32=from-isa' (and a corresponding `-mfp=from-isa' 
compiler option) would handle, got lost/forgotten in the works somehow.

 Matthew has been the expert in this area and might be able to add some 
more -- Matthew?  Also shall we call it a compiler defect?  We seem to be 
getting more and more toolchain configurations which break the existing 
setups in a way requiring them to add more and more compiler options to 
Makefiles for preexisting targets even though the Makefiles were 
previously already prepared to choose the right compiler options for the 
target.  This seems the wrong way to go to me as it's causing people 
burden when upgrading their toolchains while it's supposed to be seamless 
(it's one aspect of maintaining backwards compatibility).

 Meanwhile your proposal may be indeed the way to go, or perhaps we could 
use a substitution rule like:

$(patsubst -march=%,-mfp32,$(filter -march=r3%,$(KBUILD_CFLAGS)))

-- see the change below, it seems to work for me and the option is indeed 
passed with a `-march=r3000' build (as would with a `-march=r3900' build) 
and suppressed otherwise (such as with a `-march=mips32r2' build).  

 I have tried building `arch/mips/vdso/gettimeofday.s' to see how the 
module settings are chosen by the compiler in my successful build, and 
that produced an unexpected result in that the rule for .s targets is 
evidently broken for VDSO as different compiler flags were used from ones 
used for .o targets -- essentially the regular flags rather than the 
special VDSO ones (no `-fPIC', etc.).  So that looks like a bug to me to 
be fixed too.

 So instead I just checked the ABI annotation of a good .o object with 
`readelf':

$ readelf -A arch/mips/vdso/gettimeofday.o
Attribute Section: gnu
File Attributes
  Tag_GNU_MIPS_ABI_FP: Hard float (double precision)

MIPS ABI Flags Version: 0

ISA: MIPS1
GPR size: 32
CPR1 size: 32
CPR2 size: 0
FP ABI: Hard float (double precision)
ISA Extension: None
ASEs:
None
FLAGS 1: 
FLAGS 2: 
$ 

and I think this would be good to keep.  Obviously this will prevent 
`-mfp64' executables or DSOs from being loaded together with VDSO, but 
they are incompatible with the 32-bit FPU MIPS I processors have anyway, 
so no change in the semantics there.

 On the other hand there's still the issue w

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

[Matthew Fortune]

Maciej Rozycki  writes:
> On Tue, 1 Nov 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 
> > > > Cc: James Hogan 
> > > > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > > > Signed-off-by: Guenter Roeck 
> > > > ---
> [...]
> > >  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.
> 
>  That does not tell me anything -- I have no idea how each of the
> toolchains out there has been configured.  I can only assess information
> provided by the bug/patch submitter, and otherwise try guessing.
> 
> > 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'.
> 
>  Indeed I got that confused, even though there is supposed to be a
> mention in the compiler's diagnostics if a warning or error has
> originated from an external tool invoked.  Sorry about that.  The
> message itself could well have come from the assembler though as the
> same options are accepted by that tool.
> 
>  And indeed I have just guessed what the cause might be, that is the
> compiler must have been configured with an explicit `--with-fp-32=xx' or
> `--with-fp-32=64' option.

This is almost certainly using --with-fp-32=xx

>  Here's quite an extensive analysis of what these options do and why:
>  _FR0_and_FR1_Interlinking>
> and I note that there is a mention of a setup which would have avoided
> the situation we have now:
> 
> "Ideally any MIPS I arch/core will default to -mfp32 Any MIPS II ->
> MIPS32r2 arch/core will default to -mfpxx. However, this should be
> controlled via a configure time option to adjust the default ABI from
> O32
> FP32 to O32 FPXX (or O32 FP64 as needed). The new configure time option
> is --with-fp-32=[32|xx|64] and this affects the FP mode only when
> targetting the O32 ABI."
> 
> however this ideal arrangement, which I would expect a configuration
> option like `--with-fp-32=from-isa' (and a corresponding `-mfp=from-isa'
> compiler option) would handle, got lost/forgotten in the works somehow.

The intention of these comments was about vendor tool configurations that
often do more option inference than standard tools. We could do a
--with-fp-32=from-isa but that would not be used by debian anyway as it
does not meet the goal of reliably generating FP compatible code. There are
also subjective answers to the 'from-isa' question as mips32r1 could be
fp32 or fpxx depending on what the toolchain owner wanted to achieve.

>  Matthew has been the expert in this area and might be able to add some
> more -- Matthew?  Also shall we call it a compiler defect?  We seem to
> be getting more and more toolchain configurations which break the
> existing setups in a way requiring them to add more and more compiler
> options to Makefiles for preexisting targets even though the Makefiles
> were previously already prepared to choose the right compiler options
> for the target.  This seems the wrong way to go to me as it's causing
> people burden when upgrading their toolchains while it's supposed to be
> seamless (it's one aspect of maintaining backwards compatibility).

I agree we don't want to take decisions lightly that end up breaking
builds but we should not shy away from them.

In this specific case a kernel for a MIPS I arch is being built from a
toolchain in a distribution that requires MIPS II as a minimum and is
moving towards requiring MIPS32R2 as a minimum. The decisions made when
configuring this toolchain are there to support the intended users so
as we move forward there will be some things that stop working as
before (by default).

Given that then I think this is reasonable fall-out. The options are:
Build this configuration of the kernel using an older distribution,
Build a custom toolchain, Update the kernel to cope with this new
configuration.

In general I think it is reasonable for people to request continued
support for architectures or configurations that are older and have a
smaller user-base but such users may have to invest a little more effort
in configuring as focu

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

[Guenter Roeck]

On Fri, Nov 04, 2016 at 01:42:40PM +, Matthew Fortune wrote:
> Maciej Rozycki  writes:
> > On Tue, 1 Nov 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 
> > > > > Cc: James Hogan 
> > > > > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > > > > Signed-off-by: Guenter Roeck 
> > > > > ---
> > [...]
> > > >  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.
> > 
> >  That does not tell me anything -- I have no idea how each of the
> > toolchains out there has been configured.  I can only assess information
> > provided by the bug/patch submitter, and otherwise try guessing.
> > 
> > > 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'.
> > 
> >  Indeed I got that confused, even though there is supposed to be a
> > mention in the compiler's diagnostics if a warning or error has
> > originated from an external tool invoked.  Sorry about that.  The
> > message itself could well have come from the assembler though as the
> > same options are accepted by that tool.
> > 
> >  And indeed I have just guessed what the cause might be, that is the
> > compiler must have been configured with an explicit `--with-fp-32=xx' or
> > `--with-fp-32=64' option.
> 
> This is almost certainly using --with-fp-32=xx
> 
> >  Here's quite an extensive analysis of what these options do and why:
> >  > _FR0_and_FR1_Interlinking>
> > and I note that there is a mention of a setup which would have avoided
> > the situation we have now:
> > 
> > "Ideally any MIPS I arch/core will default to -mfp32 Any MIPS II ->
> > MIPS32r2 arch/core will default to -mfpxx. However, this should be
> > controlled via a configure time option to adjust the default ABI from
> > O32
> > FP32 to O32 FPXX (or O32 FP64 as needed). The new configure time option
> > is --with-fp-32=[32|xx|64] and this affects the FP mode only when
> > targetting the O32 ABI."
> > 
> > however this ideal arrangement, which I would expect a configuration
> > option like `--with-fp-32=from-isa' (and a corresponding `-mfp=from-isa'
> > compiler option) would handle, got lost/forgotten in the works somehow.
> 
> The intention of these comments was about vendor tool configurations that
> often do more option inference than standard tools. We could do a
> --with-fp-32=from-isa but that would not be used by debian anyway as it
> does not meet the goal of reliably generating FP compatible code. There are
> also subjective answers to the 'from-isa' question as mips32r1 could be
> fp32 or fpxx depending on what the toolchain owner wanted to achieve.
> 
> >  Matthew has been the expert in this area and might be able to add some
> > more -- Matthew?  Also shall we call it a compiler defect?  We seem to
> > be getting more and more toolchain configurations which break the
> > existing setups in a way requiring them to add more and more compiler
> > options to Makefiles for preexisting targets even though the Makefiles
> > were previously already prepared to choose the right compiler options
> > for the target.  This seems the wrong way to go to me as it's causing
> > people burden when upgrading their toolchains while it's supposed to be
> > seamless (it's one aspect of maintaining backwards compatibility).
> 
> I agree we don't want to take decisions lightly that end up breaking
> builds but we should not shy away from them.
> 
> In this specific case a kernel for a MIPS I arch is being built from a
> toolchain in a distribution that requires MIPS II as a minimum and is
> moving towards requiring MIPS32R2 as a minimum. The decisions made when
> configuring this toolchain are there to support the intended users so
> as we move forward there will be some things that stop working as
> before (by default).
> 
> Given that then I think this is reasonable fall-out. The options are:
> Build this configuration of the kernel using an older distribution,
> Build a custom toolchain, Update the kernel to cop

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

[Maciej W. Rozycki]

On Fri, 4 Nov 2016, Guenter Roeck wrote:

> > As above, unless absolutely critical to have floating point code then
> > the vDSO should just avoid all FP related issues and build soft-float.
> 
> FWIW, my logic was quite simple: The rest of the kernel builds with
> -msoft-float, thus vDSO should do the same. Of course, I don't know the
> entire context, so there may well be a reason to handle it differently
> than the rest of the kernel.

 VDSO is not a part of the kernel, it's user mode code, made visible in 
the user virtual memory, and implicitly loaded along the rest of the DSOs 
on program startup by the dynamic loader (ld.so).  It has to be PIC for 
that reason, too, causing all the hassle we had with making it such that 
it does not need a GOT.

> Anyway, isn't the kernel supposed to not use floating point operations
> in the first place ? Is this different for vDSO ?

 This code is executed in the user mode so while floating-point code may 
not be needed there, not at least right now, there's actually nothing 
which should stop us from from adding some should such a need arise.

  Maciej

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

[Guenter Roeck]

On Fri, Nov 04, 2016 at 04:09:37PM +, Maciej W. Rozycki wrote:
> On Fri, 4 Nov 2016, Guenter Roeck wrote:
> 
> > > As above, unless absolutely critical to have floating point code then
> > > the vDSO should just avoid all FP related issues and build soft-float.
> > 
> > FWIW, my logic was quite simple: The rest of the kernel builds with
> > -msoft-float, thus vDSO should do the same. Of course, I don't know the
> > entire context, so there may well be a reason to handle it differently
> > than the rest of the kernel.
> 
>  VDSO is not a part of the kernel, it's user mode code, made visible in 
> the user virtual memory, and implicitly loaded along the rest of the DSOs 
> on program startup by the dynamic loader (ld.so).  It has to be PIC for 
> that reason, too, causing all the hassle we had with making it such that 
> it does not need a GOT.
> 
> > Anyway, isn't the kernel supposed to not use floating point operations
> > in the first place ? Is this different for vDSO ?
> 
>  This code is executed in the user mode so while floating-point code may 
> not be needed there, not at least right now, there's actually nothing 
> which should stop us from from adding some should such a need arise.
> 
Just for my understanding - so the code is compiled with the kernel and part
of the kernel source but executed in user mode ?

If you ever add real floating point code, doesn't that also mean that you'll
have to implement the necessary linker helper functions or wrappers (such
as the wrappers needed for 64-bit integer divide operations in 32 bit code) ?

Thanks,
Guenter

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

[Matthew Fortune]

Maciej Rozycki  writes:
> On Fri, 4 Nov 2016, Guenter Roeck wrote:
> 
> > > As above, unless absolutely critical to have floating point code
> > > then the vDSO should just avoid all FP related issues and build
> soft-float.
...
> > Anyway, isn't the kernel supposed to not use floating point operations
> > in the first place ? Is this different for vDSO ?
> 
>  This code is executed in the user mode so while floating-point code may
> not be needed there, not at least right now, there's actually nothing
> which should stop us from from adding some should such a need arise.

Indeed. For now though the switch to -msoft-float is the simplest solution
isn't it?

Matthew

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

[Maciej W. Rozycki]

On Fri, 4 Nov 2016, Guenter Roeck wrote:

> >  This code is executed in the user mode so while floating-point code may 
> > not be needed there, not at least right now, there's actually nothing 
> > which should stop us from from adding some should such a need arise.
> > 
> Just for my understanding - so the code is compiled with the kernel and part
> of the kernel source but executed in user mode ?

 Yes, that's correct.

 The idea behind VDSO is to export some kernel data to the userland in a 
way making it possible to avoid the considerable overhead of making a 
syscall, i.e. the whole dance required to switch to the kernel mode, make 
the necessary arrangements there for kernel mode execution such as stack 
switching (see the SAVE_SOME macro), actually retrieve the data requested, 
undo the kernel mode execution arrangements (RESTORE_SOME) and finally 
resume user mode execution.

 So instead a page is mapped by the kernel in the user virtual memory with 
designated entry points comprising the public API and the actual 
implementation which retrieves the data requested in a varying way, 
depending on the kernel configuration, hardware features, etc., so it is 
tightly coupled with the kernel and has to be built along it.  These entry 
points are then used by the C library instead of their corresponding 
syscalls.

 A good use example is a replacement for gettimeofday(2).  This syscall 
retrieves a tiny amount of data which is frequently requested e.g. by X 
servers which want to individually timestamp their events.  So the gain 
from avoiding making this syscall and instead retrieving the data 
requested straight in the user mode is enormous.

> If you ever add real floating point code, doesn't that also mean that you'll
> have to implement the necessary linker helper functions or wrappers (such
> as the wrappers needed for 64-bit integer divide operations in 32 bit code) ?

 No, you could just link the VDSO with `-lgcc' instead and get all the 
necessary bits from there, as usually in user code.  Although if building 
for compat ABIs as well you'd have to ensure you have GCC libraries built 
and installed for all the ABIs required, which in turn depends on the 
configuration chosen for the compiler at its build time.  Not a problem 
right now though as we don't need any of this stuff.

 HTH,

  Maciej

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

[Guenter Roeck]

On Fri, Nov 04, 2016 at 04:55:05PM +, Matthew Fortune wrote:
> Maciej Rozycki  writes:
> > On Fri, 4 Nov 2016, Guenter Roeck wrote:
> > 
> > > > As above, unless absolutely critical to have floating point code
> > > > then the vDSO should just avoid all FP related issues and build
> > soft-float.
> ...
> > > Anyway, isn't the kernel supposed to not use floating point operations
> > > in the first place ? Is this different for vDSO ?
> > 
> >  This code is executed in the user mode so while floating-point code may
> > not be needed there, not at least right now, there's actually nothing
> > which should stop us from from adding some should such a need arise.
> 
> Indeed. For now though the switch to -msoft-float is the simplest solution
> isn't it?
> 
One should think so, especially since 1) the code has to be built as part of the
kernel build anyway, and 2) there would be other implications besides just
adding floating point operations into the kernel (see the other e-mail).
Overall I am glad that I don't have to maintain this code.

Either case, it would be great if we can come up with a solution to avoid build
failures due to toolchain configurations. If that means that vDSO won't be
compilable with debian toolchains, so be it. After all, that would not be
different to the current situation, only it would be official instead of causing
build failures.

Thanks,
Guenter

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

[Maciej W. Rozycki]

On Fri, 4 Nov 2016, Matthew Fortune wrote:

> >  This code is executed in the user mode so while floating-point code may
> > not be needed there, not at least right now, there's actually nothing
> > which should stop us from from adding some should such a need arise.
> 
> Indeed. For now though the switch to -msoft-float is the simplest solution
> isn't it?

 As I previously noted I am leaning towards accepting this solution, but 
please let me do some further research before I answer your question.  
I'll reply to your original response when I am ready.

  Maciej