[PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[James Hogan]

The native ABI vDSO linker script vdso.lds is built by preprocessing
vdso.lds.S, with the native -mabi flag passed in to get the correct ABI
definitions. Unfortunately however certain toolchains choke on -mabi=64
without a corresponding compatible -march flag, for example:

cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI
scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed

Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds,
which includes the appropriate -march flag.

Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 4.4.x-
---
 arch/mips/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 3b4538ec0102..de9e8836d248 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -82,7 +82,7 @@ obj-vdso := $(obj-vdso-y:%.o=$(obj)/%.o)
 $(obj-vdso): KBUILD_CFLAGS := $(cflags-vdso) $(native-abi)
 $(obj-vdso): KBUILD_AFLAGS := $(aflags-vdso) $(native-abi)
 
-$(obj)/vdso.lds: KBUILD_CPPFLAGS := $(native-abi)
+$(obj)/vdso.lds: KBUILD_CPPFLAGS := $(ccflags-vdso) $(native-abi)
 
 $(obj)/vdso.so.dbg.raw: $(obj)/vdso.lds $(obj-vdso) FORCE
 	$(call if_changed,vdsold)
-- 
git-series 0.8.10

[PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[James Hogan]

The native ABI vDSO linker script vdso.lds is built by preprocessing
vdso.lds.S, with the native -mabi flag passed in to get the correct ABI
definitions. Unfortunately however certain toolchains choke on -mabi=64
without a corresponding compatible -march flag, for example:

cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI
scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed

Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds,
which includes the appropriate -march flag.

Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 4.4.x-
---
 arch/mips/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 3b4538ec0102..de9e8836d248 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -82,7 +82,7 @@ obj-vdso := $(obj-vdso-y:%.o=$(obj)/%.o)
 $(obj-vdso): KBUILD_CFLAGS := $(cflags-vdso) $(native-abi)
 $(obj-vdso): KBUILD_AFLAGS := $(aflags-vdso) $(native-abi)
 
-$(obj)/vdso.lds: KBUILD_CPPFLAGS := $(native-abi)
+$(obj)/vdso.lds: KBUILD_CPPFLAGS := $(ccflags-vdso) $(native-abi)
 
 $(obj)/vdso.so.dbg.raw: $(obj)/vdso.lds $(obj-vdso) FORCE
 	$(call if_changed,vdsold)
-- 
git-series 0.8.10

Re: [PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[Maciej W. Rozycki]

On Thu, 6 Oct 2016, James Hogan wrote:

> The native ABI vDSO linker script vdso.lds is built by preprocessing
> vdso.lds.S, with the native -mabi flag passed in to get the correct ABI
> definitions. Unfortunately however certain toolchains choke on -mabi=64
> without a corresponding compatible -march flag, for example:
> 
> cc1: error: οΏ½-march=mips32r2οΏ½ is not compatible with the selected ABI
> scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed
> 
> Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds,
> which includes the appropriate -march flag.
> 
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips@linux-mips.org
> Cc: <stable@vger.kernel.org> # 4.4.x-
> ---

Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>

 NB by default GCC is configured for the default of `-march=from-abi', 
which is why saying `-mabi=64' only often works as such GCC implicitly 
switches to a compatible `-march=' setting (i.e. `mips3' vs `mips1' for 
o32).  However when configured with `-march=' set to a particular ISA 
level, such as `mips32r2' quoted above you need to select a compatible ISA 
explicitly when switching to a 64-bit ABI (arguably you could configure 
with `-march=mips64r2' instead as with a 32-bit ABI such a setting would 
limit the instruction set to the 32-bit subset automatically).

 Also I've noticed $(aflags-vdso) duplicate `-I' and `-E' options already 
included with $(ccflags-vdso); I wonder if the duplicates should simply be 
removed or whether $(cflags-vdso) ought to filter from $(KBUILD_CFLAGS) 
and $(aflags-vdso) -- from $(KBUILD_AFLAGS) instead (or $(ccflags-vdso) 
should just take the options from $(KBUILD_CPPFLAGS)).  Also why `-E' is 
supposed to take an argument?  Can you please have a look at it?

  Maciej

Re: [PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[Maciej W. Rozycki]

On Thu, 6 Oct 2016, James Hogan wrote:

> The native ABI vDSO linker script vdso.lds is built by preprocessing
> vdso.lds.S, with the native -mabi flag passed in to get the correct ABI
> definitions. Unfortunately however certain toolchains choke on -mabi=64
> without a corresponding compatible -march flag, for example:
> 
> cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI
> scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed
> 
> Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds,
> which includes the appropriate -march flag.
> 
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips@linux-mips.org
> Cc: <stable@vger.kernel.org> # 4.4.x-
> ---

Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>

 NB by default GCC is configured for the default of `-march=from-abi', 
which is why saying `-mabi=64' only often works as such GCC implicitly 
switches to a compatible `-march=' setting (i.e. `mips3' vs `mips1' for 
o32).  However when configured with `-march=' set to a particular ISA 
level, such as `mips32r2' quoted above you need to select a compatible ISA 
explicitly when switching to a 64-bit ABI (arguably you could configure 
with `-march=mips64r2' instead as with a 32-bit ABI such a setting would 
limit the instruction set to the 32-bit subset automatically).

 Also I've noticed $(aflags-vdso) duplicate `-I' and `-E' options already 
included with $(ccflags-vdso); I wonder if the duplicates should simply be 
removed or whether $(cflags-vdso) ought to filter from $(KBUILD_CFLAGS) 
and $(aflags-vdso) -- from $(KBUILD_AFLAGS) instead (or $(ccflags-vdso) 
should just take the options from $(KBUILD_CPPFLAGS)).  Also why `-E' is 
supposed to take an argument?  Can you please have a look at it?

  Maciej

Re: [PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[Maciej W. Rozycki]

On Thu, 6 Oct 2016, James Hogan wrote:

> The native ABI vDSO linker script vdso.lds is built by preprocessing
> vdso.lds.S, with the native -mabi flag passed in to get the correct ABI
> definitions. Unfortunately however certain toolchains choke on -mabi=64
> without a corresponding compatible -march flag, for example:
> 
> cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI
> scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed
> 
> Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds,
> which includes the appropriate -march flag.
> 
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips@linux-mips.org
> Cc: <stable@vger.kernel.org> # 4.4.x-
> ---

Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>

 NB by default GCC is configured for the default of `-march=from-abi', 
which is why saying `-mabi=64' only often works as such GCC implicitly 
switches to a compatible `-march=' setting (i.e. `mips3' vs `mips1' for 
o32).  However when configured with `-march=' set to a particular ISA 
level, such as `mips32r2' quoted above you need to select a compatible ISA 
explicitly when switching to a 64-bit ABI (arguably you could configure 
with `-march=mips64r2' instead as with a 32-bit ABI such a setting would 
limit the instruction set to the 32-bit subset automatically).

 Also I've noticed $(aflags-vdso) duplicate `-I' and `-E' options already 
included with $(ccflags-vdso); I wonder if the duplicates should simply be 
removed or whether $(cflags-vdso) ought to filter from $(KBUILD_CFLAGS) 
and $(aflags-vdso) -- from $(KBUILD_AFLAGS) instead (or $(ccflags-vdso) 
should just take the options from $(KBUILD_CPPFLAGS)).  Also why `-E' is 
supposed to take an argument?  Can you please have a look at it?

  Maciej

Re: [PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

On Fri, Oct 07, 2016 at 12:52:32AM +0100, Maciej W. Rozycki wrote:
> On Thu, 6 Oct 2016, James Hogan wrote:
> 
> > The native ABI vDSO linker script vdso.lds is built by preprocessing
> > vdso.lds.S, with the native -mabi flag passed in to get the correct ABI
> > definitions. Unfortunately however certain toolchains choke on -mabi=64
> > without a corresponding compatible -march flag, for example:
> > 
> > cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI
> > scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed
> > 
> > Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds,
> > which includes the appropriate -march flag.
> > 
> > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > Signed-off-by: James Hogan <james.hogan@imgtec.com>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: linux-mips@linux-mips.org
> > Cc: <stable@vger.kernel.org> # 4.4.x-
> > ---
> 
> Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>
> 
>  NB by default GCC is configured for the default of `-march=from-abi', 
> which is why saying `-mabi=64' only often works as such GCC implicitly 
> switches to a compatible `-march=' setting (i.e. `mips3' vs `mips1' for 
> o32).  However when configured with `-march=' set to a particular ISA 
> level, such as `mips32r2' quoted above you need to select a compatible ISA 
> explicitly when switching to a 64-bit ABI (arguably you could configure 
> with `-march=mips64r2' instead as with a 32-bit ABI such a setting would 
> limit the instruction set to the 32-bit subset automatically).

Thanks Maciej for the description. The toolchain in question was a
buildroot toolchain, which does I believe default to a particular
-march, so that makes a lot of sense.

> 
>  Also I've noticed $(aflags-vdso) duplicate `-I' and `-E' options already 
> included with $(ccflags-vdso); I wonder if the duplicates should simply be 
> removed or whether $(cflags-vdso) ought to filter from $(KBUILD_CFLAGS) 
> and $(aflags-vdso) -- from $(KBUILD_AFLAGS) instead (or $(ccflags-vdso) 
> should just take the options from $(KBUILD_CPPFLAGS)).  Also why `-E' is 
> supposed to take an argument?  Can you please have a look at it?

I think -E is to catch -EL / -EB. Removing the duplication is easily
fixed (I'll post a patch soon). As for whether it should filter from the
other KBUILD_ flags, I'm inclined to avoid changing it unless we can be
sure it will be more robust as a result.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

On Fri, Oct 07, 2016 at 12:52:32AM +0100, Maciej W. Rozycki wrote:
> On Thu, 6 Oct 2016, James Hogan wrote:
> 
> > The native ABI vDSO linker script vdso.lds is built by preprocessing
> > vdso.lds.S, with the native -mabi flag passed in to get the correct ABI
> > definitions. Unfortunately however certain toolchains choke on -mabi=64
> > without a corresponding compatible -march flag, for example:
> > 
> > cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI
> > scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed
> > 
> > Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds,
> > which includes the appropriate -march flag.
> > 
> > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > Signed-off-by: James Hogan <james.hogan@imgtec.com>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: linux-mips@linux-mips.org
> > Cc: <stable@vger.kernel.org> # 4.4.x-
> > ---
> 
> Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>
> 
>  NB by default GCC is configured for the default of `-march=from-abi', 
> which is why saying `-mabi=64' only often works as such GCC implicitly 
> switches to a compatible `-march=' setting (i.e. `mips3' vs `mips1' for 
> o32).  However when configured with `-march=' set to a particular ISA 
> level, such as `mips32r2' quoted above you need to select a compatible ISA 
> explicitly when switching to a 64-bit ABI (arguably you could configure 
> with `-march=mips64r2' instead as with a 32-bit ABI such a setting would 
> limit the instruction set to the 32-bit subset automatically).

Thanks Maciej for the description. The toolchain in question was a
buildroot toolchain, which does I believe default to a particular
-march, so that makes a lot of sense.

> 
>  Also I've noticed $(aflags-vdso) duplicate `-I' and `-E' options already 
> included with $(ccflags-vdso); I wonder if the duplicates should simply be 
> removed or whether $(cflags-vdso) ought to filter from $(KBUILD_CFLAGS) 
> and $(aflags-vdso) -- from $(KBUILD_AFLAGS) instead (or $(ccflags-vdso) 
> should just take the options from $(KBUILD_CPPFLAGS)).  Also why `-E' is 
> supposed to take an argument?  Can you please have a look at it?

I think -E is to catch -EL / -EB. Removing the duplication is easily
fixed (I'll post a patch soon). As for whether it should filter from the
other KBUILD_ flags, I'm inclined to avoid changing it unless we can be
sure it will be more robust as a result.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[Maciej W. Rozycki]

On Fri, 7 Oct 2016, James Hogan wrote:

> >  Also I've noticed $(aflags-vdso) duplicate `-I' and `-E' options already 
> > included with $(ccflags-vdso); I wonder if the duplicates should simply be 
> > removed or whether $(cflags-vdso) ought to filter from $(KBUILD_CFLAGS) 
> > and $(aflags-vdso) -- from $(KBUILD_AFLAGS) instead (or $(ccflags-vdso) 
> > should just take the options from $(KBUILD_CPPFLAGS)).  Also why `-E' is 
> > supposed to take an argument?  Can you please have a look at it?
> 
> I think -E is to catch -EL / -EB.

 Ahh, forgot about the existence of these!

> Removing the duplication is easily
> fixed (I'll post a patch soon). As for whether it should filter from the
> other KBUILD_ flags, I'm inclined to avoid changing it unless we can be
> sure it will be more robust as a result.

 I've only been trying to figure out what Alex might have intended here.  
Obviously given that otherwise the current setup seems to work I tend to 
agree with you in that a simple removal of the duplication is the safest 
path of the least resistance fix.

  Maciej

Re: [PATCH] MIPS: Fix -mabi=64 build of vdso.lds

[Maciej W. Rozycki]

On Fri, 7 Oct 2016, James Hogan wrote:

> >  Also I've noticed $(aflags-vdso) duplicate `-I' and `-E' options already 
> > included with $(ccflags-vdso); I wonder if the duplicates should simply be 
> > removed or whether $(cflags-vdso) ought to filter from $(KBUILD_CFLAGS) 
> > and $(aflags-vdso) -- from $(KBUILD_AFLAGS) instead (or $(ccflags-vdso) 
> > should just take the options from $(KBUILD_CPPFLAGS)).  Also why `-E' is 
> > supposed to take an argument?  Can you please have a look at it?
> 
> I think -E is to catch -EL / -EB.

 Ahh, forgot about the existence of these!

> Removing the duplication is easily
> fixed (I'll post a patch soon). As for whether it should filter from the
> other KBUILD_ flags, I'm inclined to avoid changing it unless we can be
> sure it will be more robust as a result.

 I've only been trying to figure out what Alex might have intended here.  
Obviously given that otherwise the current setup seems to work I tend to 
agree with you in that a simple removal of the duplication is the safest 
path of the least resistance fix.

  Maciej