[PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

[PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

[Nicholas Piggin]

Provide an option to use ELFv2 ABI for big endian builds. This works on
GCC and clang (since 2014). it is is not officially supported by the GNU
toolchain, but it can give some useful advantages of the ELFv2 ABI for
BE (e.g., less stack usage). Some distros build BE ELFv2 userspace.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
 arch/powerpc/Kconfig            | 19 +++++++++++++++++++
 arch/powerpc/Makefile           | 15 ++++++++++-----
 arch/powerpc/boot/Makefile      |  4 ++++
 drivers/crypto/vmx/Makefile     |  4 ++++
 drivers/crypto/vmx/aesp8-ppc.pl |  2 +-
 drivers/crypto/vmx/ppc-xlate.pl | 11 +++++++----
 6 files changed, 45 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 497b7d0b2d7e..31dd921a5145 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -146,6 +146,7 @@ config PPC
 	select ARCH_WEAK_RELEASE_ACQUIRE
 	select BINFMT_ELF
 	select BUILDTIME_TABLE_SORT
+	select BUILD_ELF_V2			if PPC64 && CPU_LITTLE_ENDIAN
 	select CLONE_BACKWARDS
 	select DCACHE_WORD_ACCESS		if PPC64 && CPU_LITTLE_ENDIAN
 	select DYNAMIC_FTRACE			if FUNCTION_TRACER
@@ -538,6 +539,24 @@ config KEXEC_FILE
 config ARCH_HAS_KEXEC_PURGATORY
 	def_bool KEXEC_FILE
 
+config BUILD_ELF_V2
+	bool
+
+config BUILD_BIG_ENDIAN_ELF_V2
+	bool "Build big-endian kernel using ELFv2 ABI (EXPERIMENTAL)"
+	depends on PPC64 && CPU_BIG_ENDIAN && EXPERT
+	default n
+	select BUILD_ELF_V2
+	help
+	  This builds the kernel image using the ELFv2 ABI, which has a
+	  reduced stack overhead and faster function calls. This does not
+	  affect the userspace ABIs.
+
+	  ELFv2 is the standard ABI for little-endian, but for big-endian
+	  this is an experimental option that is not well tested (kernel and
+	  toolchain). This requires gcc 4.9 or newer and binutils 2.24 or
+	  newer.
+
 config RELOCATABLE
 	bool "Build a relocatable kernel"
 	depends on PPC64 || (FLATMEM && (44x || FSL_BOOKE))
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f35730548e42..ae8036a0b169 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -92,10 +92,14 @@ endif
 
 ifdef CONFIG_PPC64
 ifndef CONFIG_CC_IS_CLANG
-cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= $(call cc-option,-mabi=elfv1)
-cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= $(call cc-option,-mcall-aixdesc)
-aflags-$(CONFIG_CPU_BIG_ENDIAN)		+= $(call cc-option,-mabi=elfv1)
-aflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -mabi=elfv2
+ifdef CONFIG_BUILD_ELF_V2
+cflags-y				+= $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
+aflags-y				+= $(call cc-option,-mabi=elfv2)
+else
+cflags-y				+= $(call cc-option,-mabi=elfv1)
+cflags-y				+= $(call cc-option,-mcall-aixdesc)
+aflags-y				+= $(call cc-option,-mabi=elfv1)
+endif
 endif
 endif
 
@@ -144,7 +148,7 @@ endif
 
 CFLAGS-$(CONFIG_PPC64)	:= $(call cc-option,-mtraceback=no)
 ifndef CONFIG_CC_IS_CLANG
-ifdef CONFIG_CPU_LITTLE_ENDIAN
+ifdef CONFIG_BUILD_ELF_V2
 CFLAGS-$(CONFIG_PPC64)	+= $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
 AFLAGS-$(CONFIG_PPC64)	+= $(call cc-option,-mabi=elfv2)
 else
@@ -153,6 +157,7 @@ CFLAGS-$(CONFIG_PPC64)	+= $(call cc-option,-mcall-aixdesc)
 AFLAGS-$(CONFIG_PPC64)	+= $(call cc-option,-mabi=elfv1)
 endif
 endif
+
 CFLAGS-$(CONFIG_PPC64)	+= $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc))
 CFLAGS-$(CONFIG_PPC64)	+= $(call cc-option,-mno-pointers-to-nested-functions)
 
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 0556bf4fc9e9..137ff20b13f8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -41,6 +41,10 @@ endif
 
 BOOTCFLAGS	+= -isystem $(shell $(BOOTCC) -print-file-name=include)
 
+ifdef CONFIG_BUILD_ELF_V2
+BOOTCFLAGS	+= $(call cc-option,-mabi=elfv2)
+endif
+
 ifdef CONFIG_CPU_BIG_ENDIAN
 BOOTCFLAGS	+= -mbig-endian
 else
diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
index 709670d2b553..8d79514eb474 100644
--- a/drivers/crypto/vmx/Makefile
+++ b/drivers/crypto/vmx/Makefile
@@ -5,8 +5,12 @@ vmx-crypto-objs := vmx.o aesp8-ppc.o ghashp8-ppc.o aes.o aes_cbc.o aes_ctr.o aes
 ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
 override flavour := linux-ppc64le
 else
+ifdef CONFIG_BUILD_ELF_V2
+override flavour := linux-ppc64v2
+else
 override flavour := linux-ppc64
 endif
+endif
 
 quiet_cmd_perl = PERL $@
       cmd_perl = $(PERL) $(<) $(flavour) > $(@)
diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
index db874367b602..6733a68f12ed 100644
--- a/drivers/crypto/vmx/aesp8-ppc.pl
+++ b/drivers/crypto/vmx/aesp8-ppc.pl
@@ -100,7 +100,7 @@ if ($flavour =~ /64/) {
 	$SHL	="slwi";
 } else { die "nonsense $flavour"; }
 
-$LITTLE_ENDIAN = ($flavour=~/le$/) ? $SIZE_T : 0;
+$LITTLE_ENDIAN = ($flavour=~/ppc64le/) ? $SIZE_T : 0;
 
 $0 =~ m/(.*[\/\\])[^\/\\]+$/; $dir=$1;
 ( $xlate="${dir}ppc-xlate.pl" and -f $xlate ) or
diff --git a/drivers/crypto/vmx/ppc-xlate.pl b/drivers/crypto/vmx/ppc-xlate.pl
index 36db2ef09e5b..5f9963ae100e 100644
--- a/drivers/crypto/vmx/ppc-xlate.pl
+++ b/drivers/crypto/vmx/ppc-xlate.pl
@@ -9,6 +9,8 @@ open STDOUT,">$output" || die "can't open $output: $!";
 
 my %GLOBALS;
 my $dotinlocallabels=($flavour=~/linux/)?1:0;
+my $abielfv2=(($flavour =~ /linux-ppc64le/) or ($flavour =~ /linux-ppc64v2/))?1:0;
+my $dotfunctions=($abielfv2=~1)?0:1;
 
 ################################################################
 # directives which need special treatment on different platforms
@@ -38,9 +40,10 @@ my $globl = sub {
     $$global = $name;
     $ret;
 };
+
 my $text = sub {
     my $ret = ($flavour =~ /aix/) ? ".csect\t.text[PR],7" : ".text";
-    $ret = ".abiversion	2\n".$ret	if ($flavour =~ /linux.*64le/);
+    $ret = ".abiversion	2\n".$ret	if ($abielfv2);
     $ret;
 };
 my $machine = sub {
@@ -56,8 +59,8 @@ my $size = sub {
     if ($flavour =~ /linux/)
     {	shift;
 	my $name = shift; $name =~ s|^[\.\_]||;
-	my $ret  = ".size	$name,.-".($flavour=~/64$/?".":"").$name;
-	$ret .= "\n.size	.$name,.-.$name" if ($flavour=~/64$/);
+	my $ret  = ".size	$name,.-".($dotfunctions?".":"").$name;
+	$ret .= "\n.size	.$name,.-.$name" if ($dotfunctions);
 	$ret;
     }
     else
@@ -142,7 +145,7 @@ my $vmr = sub {
 
 # Some ABIs specify vrsave, special-purpose register #256, as reserved
 # for system use.
-my $no_vrsave = ($flavour =~ /linux-ppc64le/);
+my $no_vrsave = ($abielfv2);
 my $mtspr = sub {
     my ($f,$idx,$ra) = @_;
     if ($idx == 256 && $no_vrsave) {
-- 
2.23.0

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

[Segher Boessenkool]

Hi!

On Tue, Mar 03, 2020 at 11:45:27AM +1000, Nicholas Piggin wrote:
> Provide an option to use ELFv2 ABI for big endian builds. This works on
> GCC and clang (since 2014). it is is not officially supported by the GNU
> toolchain, but it can give some useful advantages of the ELFv2 ABI for
> BE (e.g., less stack usage). Some distros build BE ELFv2 userspace.

It is not officially supported in the sense that a) as a host config,
it does not exist *at all* (this isn't relevant for the kernel, it does
not use a libc or other libraries, of course); and b) as a target config,
it is not supported in the sense that no one tests it, so we cannot say
anything about what quality code it generates, if it works at all, etc.

But we *do* allow "-mbig -mabi=elfv2", it's just a chicken-and-egg
problem to have this properly tested.  If someone would regularly test
it (incl. sending the test results to gcc-testresults@), I don't see why
it would not become a supported platform.

> +override flavour := linux-ppc64v2

That isn't a good name, heh.  This isn't "v2" of anything...  Spell out
the name "ELFv2"?  Or as "elfv2"?  It is just a name after all, it is
version 1 in all three version fields in the ELF headers!


Anyway, looks like it will work, let's see where this goes :-)

Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>


Segher

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

[Nicholas Piggin]

Segher Boessenkool's on March 4, 2020 9:09 am:
> Hi!
> 
> On Tue, Mar 03, 2020 at 11:45:27AM +1000, Nicholas Piggin wrote:
>> Provide an option to use ELFv2 ABI for big endian builds. This works on
>> GCC and clang (since 2014). it is is not officially supported by the GNU
>> toolchain, but it can give some useful advantages of the ELFv2 ABI for
>> BE (e.g., less stack usage). Some distros build BE ELFv2 userspace.
> 
> It is not officially supported in the sense that a) as a host config,
> it does not exist *at all* (this isn't relevant for the kernel, it does
> not use a libc or other libraries, of course); and b) as a target config,
> it is not supported in the sense that no one tests it, so we cannot say
> anything about what quality code it generates, if it works at all, etc.

Yep.

> But we *do* allow "-mbig -mabi=elfv2", it's just a chicken-and-egg
> problem to have this properly tested.  If someone would regularly test
> it (incl. sending the test results to gcc-testresults@), I don't see why
> it would not become a supported platform.
> 
>> +override flavour := linux-ppc64v2
> 
> That isn't a good name, heh.  This isn't "v2" of anything...  Spell out
> the name "ELFv2"?  Or as "elfv2"?  It is just a name after all, it is
> version 1 in all three version fields in the ELF headers!

Yeah okay. This part is only for some weird little perl asm generator
script, but probably better to be careful. linux-ppc64-elfv2 ?

> 
> 
> Anyway, looks like it will work, let's see where this goes :-)
> 
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
> 
> 
> Segher
> 

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

[Segher Boessenkool]

On Thu, Mar 05, 2020 at 01:34:22PM +1000, Nicholas Piggin wrote:
> Segher Boessenkool's on March 4, 2020 9:09 am:
> >> +override flavour := linux-ppc64v2
> > 
> > That isn't a good name, heh.  This isn't "v2" of anything...  Spell out
> > the name "ELFv2"?  Or as "elfv2"?  It is just a name after all, it is
> > version 1 in all three version fields in the ELF headers!
> 
> Yeah okay. This part is only for some weird little perl asm generator
> script, but probably better to be careful. linux-ppc64-elfv2 ?

That generator is from openssl, or inspired by it, it is everywhere.
So it is more important to get it right than it would seem at first
glance ;-)

That name looks perfect to me.  You'll have to update REs expecting the
arch at the end (like /le$/), but you had to already I think?


Segher

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

[Nicholas Piggin]

Segher Boessenkool's on March 5, 2020 8:55 pm:
> On Thu, Mar 05, 2020 at 01:34:22PM +1000, Nicholas Piggin wrote:
>> Segher Boessenkool's on March 4, 2020 9:09 am:
>> >> +override flavour := linux-ppc64v2
>> > 
>> > That isn't a good name, heh.  This isn't "v2" of anything...  Spell out
>> > the name "ELFv2"?  Or as "elfv2"?  It is just a name after all, it is
>> > version 1 in all three version fields in the ELF headers!
>> 
>> Yeah okay. This part is only for some weird little perl asm generator
>> script, but probably better to be careful. linux-ppc64-elfv2 ?
> 
> That generator is from openssl, or inspired by it, it is everywhere.
> So it is more important to get it right than it would seem at first
> glance ;-)
> 
> That name looks perfect to me.  You'll have to update REs expecting the
> arch at the end (like /le$/), but you had to already I think?

le$ is still okay for testing ppc64le, unless you wanted me to add the 
-elfv2 suffix on there as well? If that was the case, for consistency
we'd also have to add -elfv1 for the BE v1 case. I was just going to add
-elfv2 for the new variant.

Thanks,
Nick

Re: [PATCH] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

[Segher Boessenkool]

On Sat, Mar 07, 2020 at 10:58:54AM +1000, Nicholas Piggin wrote:
> Segher Boessenkool's on March 5, 2020 8:55 pm:
> > That name looks perfect to me.  You'll have to update REs expecting the
> > arch at the end (like /le$/), but you had to already I think?
> 
> le$ is still okay for testing ppc64le, unless you wanted me to add the 
> -elfv2 suffix on there as well? If that was the case, for consistency
> we'd also have to add -elfv1 for the BE v1 case. I was just going to add
> -elfv2 for the new variant.

I was thinking that, yes, but your plan is better alright (there aren't
many supported configs at all, anyway!)


Segher