diff mbox series

powerpc: Add gpr1 and fpu save/restore functions

Message ID 995988479.14839534.1707756078600.JavaMail.zimbra@raptorengineeringinc.com (mailing list archive)
State Superseded
Headers show
Series powerpc: Add gpr1 and fpu save/restore functions | expand

Checks

Context Check Description
snowpatch_ozlabs/github-powerpc_ppctests success Successfully ran 8 jobs.
snowpatch_ozlabs/github-powerpc_selftests success Successfully ran 8 jobs.
snowpatch_ozlabs/github-powerpc_clang success Successfully ran 6 jobs.
snowpatch_ozlabs/github-powerpc_sparse success Successfully ran 4 jobs.
snowpatch_ozlabs/github-powerpc_kernel_qemu success Successfully ran 23 jobs.

Commit Message

Timothy Pearson Feb. 12, 2024, 4:41 p.m. UTC
When building the kernel in size optimized mode with the amdgpu module enabled,
gcc will begin referencing external gpr1 and fpu save/restore functions.  This
will then cause a linker failure as we do not link against libgcc which
normally contains those builtin functions.

Implement gpr1 and fpu save/restore functions per the ABI v2 documentation.

Tested on a Talos II with a WX7100 installed and running in DisplayCore mode.

Reported-by: kernel test robot <lkp@intel.com>
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
---
 arch/powerpc/kernel/prom_init_check.sh |   4 +-
 arch/powerpc/lib/crtsavres.S           | 244 +++++++++++++++++++++++++
 scripts/mod/modpost.c                  |   4 +
 3 files changed, 250 insertions(+), 2 deletions(-)

Comments

Segher Boessenkool Feb. 12, 2024, 5:02 p.m. UTC | #1
On Mon, Feb 12, 2024 at 10:41:18AM -0600, Timothy Pearson wrote:
> Implement gpr1 and fpu save/restore functions per the ABI v2 documentation.

There is no "ABI v2".  This is the ELFv2 ABI, it is a name, it is not a
version 2 of anything (in fact, it is version 1 everywhere).

The same functions are needed and used in other ABIs, too.

But, why do this patch?  You just need

+LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)

+libs-y += $(LIBGCC)

and nothing more.  It is required for proper functioning of GCC to link
with the libgcc support library.


Segher
Timothy Pearson Feb. 12, 2024, 5:09 p.m. UTC | #2
----- Original Message -----
> From: "Segher Boessenkool" <segher@kernel.crashing.org>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>
> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
> Sent: Monday, February 12, 2024 11:02:07 AM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

> On Mon, Feb 12, 2024 at 10:41:18AM -0600, Timothy Pearson wrote:
>> Implement gpr1 and fpu save/restore functions per the ABI v2 documentation.
> 
> There is no "ABI v2".  This is the ELFv2 ABI, it is a name, it is not a
> version 2 of anything (in fact, it is version 1 everywhere).

Apologies, I wasn't precise on the name.

> The same functions are needed and used in other ABIs, too.
> 
> But, why do this patch?  You just need
> 
> +LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> 
> +libs-y += $(LIBGCC)
> 
> and nothing more.  It is required for proper functioning of GCC to link
> with the libgcc support library.

There is existing code in the kernel right now to provide support functions for gpr0 and altivec save/restore.  I don't know the full story here, but at some point in the kernel's history it seems to have been decided to provide the helper functions in lieu of linking libgcc directly.  If this is incorrect, then I need to know that so I can rework the patch to enable libcc and remove the existing support functions.

Is there anyone on-list that knows more of the history and decision-making that went into the current state of the kernel here?

Thanks!
Segher Boessenkool Feb. 12, 2024, 5:30 p.m. UTC | #3
On Mon, Feb 12, 2024 at 11:09:38AM -0600, Timothy Pearson wrote:
> There is existing code in the kernel right now to provide support functions for gpr0 and altivec save/restore.  I don't know the full story here, but at some point in the kernel's history it seems to have been decided to provide the helper functions in lieu of linking libgcc directly.  If this is incorrect, then I need to know that so I can rework the patch to enable libcc and remove the existing support functions.
> 
> Is there anyone on-list that knows more of the history and decision-making that went into the current state of the kernel here?

Long long time ago, linux-0.11 or something, it was discovered that some
programmiing mistakes resulted in double-length divisions (64x64->64 on
32-bit systems, say).  Most architectures have no hardware support for
that, x86 is one of those; so you need very expensive support routines
to do that (_udivdi3 or _divdi3 in that case, ...ti3 on 64-bit archs).

So it was decided to not link to libgcc to avoid this.  But that means
that all the extremely many other suppoort routines, more for some other
archs, are also not there.  While it would have been much easier to just
link to something that provides the _{u,}divdi3 symbol and then causes a
forced linking error from that!


Segher
Timothy Pearson Feb. 12, 2024, 5:46 p.m. UTC | #4
----- Original Message -----
> From: "Segher Boessenkool" <segher@kernel.crashing.org>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>
> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
> Sent: Monday, February 12, 2024 11:30:43 AM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
> 
> Long long time ago, linux-0.11 or something, it was discovered that some
> programmiing mistakes resulted in double-length divisions (64x64->64 on
> 32-bit systems, say).  Most architectures have no hardware support for
> that, x86 is one of those; so you need very expensive support routines
> to do that (_udivdi3 or _divdi3 in that case, ...ti3 on 64-bit archs).
> 
> So it was decided to not link to libgcc to avoid this.  But that means
> that all the extremely many other suppoort routines, more for some other
> archs, are also not there.  While it would have been much easier to just
> link to something that provides the _{u,}divdi3 symbol and then causes a
> forced linking error from that!
> 
> 
> Segher

Interesting, that make sense.

How should we proceed from the current situation?  Bringing in libgcc seems
like a fairly invasive change, should we merge this to fix the current bug
(cannot build ppc64 kernel in size-optimized mode) and start discussion on
bringing in libgcc as the long-term fix across multiple architectures?

My goal here is to not have to carry a downstream patch in perpetuity for
our embedded Linux firmware, which needs to be compiled in size-optimized
mode due to hardware Flash limitations.

Thanks!
Segher Boessenkool Feb. 12, 2024, 5:59 p.m. UTC | #5
On Mon, Feb 12, 2024 at 11:46:19AM -0600, Timothy Pearson wrote:
> Interesting, that make sense.
> 
> How should we proceed from the current situation?  Bringing in libgcc seems
> like a fairly invasive change,

I have done it for *all* architectures some ten years ago.  Never found
any problem.

> should we merge this to fix the current bug
> (cannot build ppc64 kernel in size-optimized mode) and start discussion on
> bringing in libgcc as the long-term fix across multiple architectures?
> 
> My goal here is to not have to carry a downstream patch in perpetuity for
> our embedded Linux firmware, which needs to be compiled in size-optimized
> mode due to hardware Flash limitations.

There are better options than -Os, fwiw.  Some --param's give smaller
*and* faster kernels.  What exactly is best is heavily arch-dependent
though (as well as dependent on the application code, the kernel code in
this case) :-(


Segher
Timothy Pearson Feb. 12, 2024, 6:07 p.m. UTC | #6
----- Original Message -----
> From: "Segher Boessenkool" <segher@kernel.crashing.org>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>
> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
> Sent: Monday, February 12, 2024 11:59:06 AM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

> On Mon, Feb 12, 2024 at 11:46:19AM -0600, Timothy Pearson wrote:
>> Interesting, that make sense.
>> 
>> How should we proceed from the current situation?  Bringing in libgcc seems
>> like a fairly invasive change,
> 
> I have done it for *all* architectures some ten years ago.  Never found
> any problem.

That makes sense, what I mean by invasive is that we'd need buy-in from the other
maintainers across all of the affected architectures.  Is that likely to occur?

>> should we merge this to fix the current bug
>> (cannot build ppc64 kernel in size-optimized mode) and start discussion on
>> bringing in libgcc as the long-term fix across multiple architectures?
>> 
>> My goal here is to not have to carry a downstream patch in perpetuity for
>> our embedded Linux firmware, which needs to be compiled in size-optimized
>> mode due to hardware Flash limitations.
> 
> There are better options than -Os, fwiw.  Some --param's give smaller
> *and* faster kernels.  What exactly is best is heavily arch-dependent
> though (as well as dependent on the application code, the kernel code in
> this case) :-(

I've been through this a few times, and -Os is the only option that makes
things (just barely) fit unfortunately.
Segher Boessenkool Feb. 12, 2024, 6:23 p.m. UTC | #7
On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:
> > I have done it for *all* architectures some ten years ago.  Never found
> > any problem.
> 
> That makes sense, what I mean by invasive is that we'd need buy-in from the other
> maintainers across all of the affected architectures.  Is that likely to occur?

I don't know.  Here is my PowerPC-specific patch, it's a bit older, it
might not apply cleanly anymore, the changes needed should be obvious
though:


=== 8< ===
commit f16dfa5257eb14549ce22243fb2b465615085134
Author: Segher Boessenkool <segher@kernel.crashing.org>
Date:   Sat May 3 03:48:06 2008 +0200

    powerpc: Link vmlinux against libgcc.a

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b7212b619c52..0a2fac6ffc1c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -158,6 +158,9 @@ core-y                              += arch/powerpc/kernel/ 
 core-$(CONFIG_XMON)            += arch/powerpc/xmon/
 core-$(CONFIG_KVM)             += arch/powerpc/kvm/
 
+LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
+libs-y += $(LIBGCC)
+
 drivers-$(CONFIG_OPROFILE)     += arch/powerpc/oprofile/
 
 # Default to zImage, override when needed
=== 8< ===


> > There are better options than -Os, fwiw.  Some --param's give smaller
> > *and* faster kernels.  What exactly is best is heavily arch-dependent
> > though (as well as dependent on the application code, the kernel code in
> > this case) :-(
> 
> I've been through this a few times, and -Os is the only option that makes
> things (just barely) fit unfortunately.

-O2 with appropriate inlining tuning beats -Os every day of the week,
in my experience.


Segher
Timothy Pearson Feb. 12, 2024, 6:31 p.m. UTC | #8
----- Original Message -----
> From: "Segher Boessenkool" <segher@kernel.crashing.org>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>
> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
> Sent: Monday, February 12, 2024 12:23:22 PM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

> On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:
>> > I have done it for *all* architectures some ten years ago.  Never found
>> > any problem.
>> 
>> That makes sense, what I mean by invasive is that we'd need buy-in from the
>> other
>> maintainers across all of the affected architectures.  Is that likely to occur?
> 
> I don't know.  Here is my PowerPC-specific patch, it's a bit older, it
> might not apply cleanly anymore, the changes needed should be obvious
> though:
> 
> 
> === 8< ===
> commit f16dfa5257eb14549ce22243fb2b465615085134
> Author: Segher Boessenkool <segher@kernel.crashing.org>
> Date:   Sat May 3 03:48:06 2008 +0200
> 
>    powerpc: Link vmlinux against libgcc.a
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index b7212b619c52..0a2fac6ffc1c 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -158,6 +158,9 @@ core-y                              += arch/powerpc/kernel/
> core-$(CONFIG_XMON)            += arch/powerpc/xmon/
> core-$(CONFIG_KVM)             += arch/powerpc/kvm/
> 
> +LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> +libs-y += $(LIBGCC)
> +
> drivers-$(CONFIG_OPROFILE)     += arch/powerpc/oprofile/
> 
> # Default to zImage, override when needed
> === 8< ===

OK.  PowerPC maintainers, how would you prefer to handle this?

>> > There are better options than -Os, fwiw.  Some --param's give smaller
>> > *and* faster kernels.  What exactly is best is heavily arch-dependent
>> > though (as well as dependent on the application code, the kernel code in
>> > this case) :-(
>> 
>> I've been through this a few times, and -Os is the only option that makes
>> things (just barely) fit unfortunately.
> 
> -O2 with appropriate inlining tuning beats -Os every day of the week,
> in my experience.

On 6.6 it's 24MiB vs 40MiB, O2 vs. Os. :(
Michael Ellerman Feb. 13, 2024, 5:23 a.m. UTC | #9
Timothy Pearson <tpearson@raptorengineering.com> writes:
> ----- Original Message -----
>> From: "Segher Boessenkool" <segher@kernel.crashing.org>
>> To: "Timothy Pearson" <tpearson@raptorengineering.com>
>> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
>> Sent: Monday, February 12, 2024 12:23:22 PM
>> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
>
>> On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:
>>> > I have done it for *all* architectures some ten years ago.  Never found
>>> > any problem.
>>> 
>>> That makes sense, what I mean by invasive is that we'd need buy-in from the
>>> other
>>> maintainers across all of the affected architectures.  Is that likely to occur?
>> 
>> I don't know.  Here is my PowerPC-specific patch, it's a bit older, it
>> might not apply cleanly anymore, the changes needed should be obvious
>> though:
>> 
>> 
>> === 8< ===
>> commit f16dfa5257eb14549ce22243fb2b465615085134
>> Author: Segher Boessenkool <segher@kernel.crashing.org>
>> Date:   Sat May 3 03:48:06 2008 +0200
>> 
>>    powerpc: Link vmlinux against libgcc.a
>> 
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index b7212b619c52..0a2fac6ffc1c 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -158,6 +158,9 @@ core-y                              += arch/powerpc/kernel/
>> core-$(CONFIG_XMON)            += arch/powerpc/xmon/
>> core-$(CONFIG_KVM)             += arch/powerpc/kvm/
>> 
>> +LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
>> +libs-y += $(LIBGCC)
>> +
>> drivers-$(CONFIG_OPROFILE)     += arch/powerpc/oprofile/
>> 
>> # Default to zImage, override when needed
>> === 8< ===
>
> OK.  PowerPC maintainers, how would you prefer to handle this?

I'll take the patch to add the functions for now. We can look into
linking against libgcc as a future cleanup.

>>> > There are better options than -Os, fwiw.  Some --param's give smaller
>>> > *and* faster kernels.  What exactly is best is heavily arch-dependent
>>> > though (as well as dependent on the application code, the kernel code in
>>> > this case) :-(
>>> 
>>> I've been through this a few times, and -Os is the only option that makes
>>> things (just barely) fit unfortunately.
>> 
>> -O2 with appropriate inlining tuning beats -Os every day of the week,
>> in my experience.
>
> On 6.6 it's 24MiB vs 40MiB, O2 vs. Os. :(

What compiler/config etc. are you using for that?

I see almost no difference, though the defconfig (which uses -O2) is
actually smaller:

$ ls -l vmlinux.Os vmlinux.defconfig
-rwxr-xr-x. 1 michael michael 49936640 Feb 13 16:11 vmlinux.defconfig*
-rwxr-xr-x. 1 michael michael 50108392 Feb 13 16:14 vmlinux.Os*

cheers
Timothy Pearson Feb. 13, 2024, 5:28 a.m. UTC | #10
----- Original Message -----
> From: "Michael Ellerman" <mpe@ellerman.id.au>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>, "Segher Boessenkool" <segher@kernel.crashing.org>
> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
> Sent: Monday, February 12, 2024 11:23:30 PM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

> Timothy Pearson <tpearson@raptorengineering.com> writes:
>> ----- Original Message -----
>>> From: "Segher Boessenkool" <segher@kernel.crashing.org>
>>> To: "Timothy Pearson" <tpearson@raptorengineering.com>
>>> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
>>> Sent: Monday, February 12, 2024 12:23:22 PM
>>> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
>>
>>> On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:
>>>> > I have done it for *all* architectures some ten years ago.  Never found
>>>> > any problem.
>>>> 
>>>> That makes sense, what I mean by invasive is that we'd need buy-in from the
>>>> other
>>>> maintainers across all of the affected architectures.  Is that likely to occur?
>>> 
>>> I don't know.  Here is my PowerPC-specific patch, it's a bit older, it
>>> might not apply cleanly anymore, the changes needed should be obvious
>>> though:
>>> 
>>> 
>>> === 8< ===
>>> commit f16dfa5257eb14549ce22243fb2b465615085134
>>> Author: Segher Boessenkool <segher@kernel.crashing.org>
>>> Date:   Sat May 3 03:48:06 2008 +0200
>>> 
>>>    powerpc: Link vmlinux against libgcc.a
>>> 
>>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>>> index b7212b619c52..0a2fac6ffc1c 100644
>>> --- a/arch/powerpc/Makefile
>>> +++ b/arch/powerpc/Makefile
>>> @@ -158,6 +158,9 @@ core-y                              += arch/powerpc/kernel/
>>> core-$(CONFIG_XMON)            += arch/powerpc/xmon/
>>> core-$(CONFIG_KVM)             += arch/powerpc/kvm/
>>> 
>>> +LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
>>> +libs-y += $(LIBGCC)
>>> +
>>> drivers-$(CONFIG_OPROFILE)     += arch/powerpc/oprofile/
>>> 
>>> # Default to zImage, override when needed
>>> === 8< ===
>>
>> OK.  PowerPC maintainers, how would you prefer to handle this?
> 
> I'll take the patch to add the functions for now. We can look into
> linking against libgcc as a future cleanup.

Sounds good.

>>>> > There are better options than -Os, fwiw.  Some --param's give smaller
>>>> > *and* faster kernels.  What exactly is best is heavily arch-dependent
>>>> > though (as well as dependent on the application code, the kernel code in
>>>> > this case) :-(
>>>> 
>>>> I've been through this a few times, and -Os is the only option that makes
>>>> things (just barely) fit unfortunately.
>>> 
>>> -O2 with appropriate inlining tuning beats -Os every day of the week,
>>> in my experience.
>>
>> On 6.6 it's 24MiB vs 40MiB, O2 vs. Os. :(
> 
> What compiler/config etc. are you using for that?

It's the kernel config that buildroot generates for skiroot -- I think a lot of the size difference is in some of the modules that we enable such as amdgpu, but haven't dug too deeply.  Once this firmware release is in beta (and therefore published publicly) I'll send over a link to the configs.

Thanks!
diff mbox series

Patch

diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh
index 69623b9045d5..76c5651e29d3 100644
--- a/arch/powerpc/kernel/prom_init_check.sh
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -72,10 +72,10 @@  do
 
 	# ignore register save/restore funcitons
 	case $UNDEF in
-	_restgpr_*|_restgpr0_*|_rest32gpr_*)
+	_restgpr_*|_restgpr0_*|_restgpr1_*|_rest32gpr_*)
 		OK=1
 		;;
-	_savegpr_*|_savegpr0_*|_save32gpr_*)
+	_savegpr_*|_savegpr0_*|_restgpr0_*|_save32gpr_*)
 		OK=1
 		;;
 	esac
diff --git a/arch/powerpc/lib/crtsavres.S b/arch/powerpc/lib/crtsavres.S
index 7e5e1c28e56a..6cd870aacd7f 100644
--- a/arch/powerpc/lib/crtsavres.S
+++ b/arch/powerpc/lib/crtsavres.S
@@ -3,6 +3,7 @@ 
  *
  *   Copyright (C) 1995, 1996, 1998, 2000, 2001 Free Software Foundation, Inc.
  *   Copyright 2008 Freescale Semiconductor, Inc.
+ *   Copyright 2024 Raptor Engineering, LLC
  *   Written By Michael Meissner
  *
  * Based on gcc/config/rs6000/crtsavres.asm from gcc
@@ -435,6 +436,127 @@  _restgpr0_31:
 	mtlr	r0
 	blr
 
+.globl	_savegpr1_14
+_savegpr1_14:
+	std	r14,-144(r12)
+.globl	_savegpr1_15
+_savegpr1_15:
+	std	r15,-136(r12)
+.globl	_savegpr1_16
+_savegpr1_16:
+	std	r16,-128(r12)
+.globl	_savegpr1_17
+_savegpr1_17:
+	std	r17,-120(r12)
+.globl	_savegpr1_18
+_savegpr1_18:
+	std	r18,-112(r12)
+.globl	_savegpr1_19
+_savegpr1_19:
+	std	r19,-104(r12)
+.globl	_savegpr1_20
+_savegpr1_20:
+	std	r20,-96(r12)
+.globl	_savegpr1_21
+_savegpr1_21:
+	std	r21,-88(r12)
+.globl	_savegpr1_22
+_savegpr1_22:
+	std	r22,-80(r12)
+.globl	_savegpr1_23
+_savegpr1_23:
+	std	r23,-72(r12)
+.globl	_savegpr1_24
+_savegpr1_24:
+	std	r24,-64(r12)
+.globl	_savegpr1_25
+_savegpr1_25:
+	std	r25,-56(r12)
+.globl	_savegpr1_26
+_savegpr1_26:
+	std	r26,-48(r12)
+.globl	_savegpr1_27
+_savegpr1_27:
+	std	r27,-40(r12)
+.globl	_savegpr1_28
+_savegpr1_28:
+	std	r28,-32(r12)
+.globl	_savegpr1_29
+_savegpr1_29:
+	std	r29,-24(r12)
+.globl	_savegpr1_30
+_savegpr1_30:
+	std	r30,-16(r12)
+.globl	_savegpr1_31
+_savegpr1_31:
+	std	r31,-8(r12)
+	std	r0,16(r12)
+	blr
+
+.globl	_restgpr1_14
+_restgpr1_14:
+	ld	r14,-144(r12)
+.globl	_restgpr1_15
+_restgpr1_15:
+	ld	r15,-136(r12)
+.globl	_restgpr1_16
+_restgpr1_16:
+	ld	r16,-128(r12)
+.globl	_restgpr1_17
+_restgpr1_17:
+	ld	r17,-120(r12)
+.globl	_restgpr1_18
+_restgpr1_18:
+	ld	r18,-112(r12)
+.globl	_restgpr1_19
+_restgpr1_19:
+	ld	r19,-104(r12)
+.globl	_restgpr1_20
+_restgpr1_20:
+	ld	r20,-96(r12)
+.globl	_restgpr1_21
+_restgpr1_21:
+	ld	r21,-88(r12)
+.globl	_restgpr1_22
+_restgpr1_22:
+	ld	r22,-80(r12)
+.globl	_restgpr1_23
+_restgpr1_23:
+	ld	r23,-72(r12)
+.globl	_restgpr1_24
+_restgpr1_24:
+	ld	r24,-64(r12)
+.globl	_restgpr1_25
+_restgpr1_25:
+	ld	r25,-56(r12)
+.globl	_restgpr1_26
+_restgpr1_26:
+	ld	r26,-48(r12)
+.globl	_restgpr1_27
+_restgpr1_27:
+	ld	r27,-40(r12)
+.globl	_restgpr1_28
+_restgpr1_28:
+	ld	r28,-32(r12)
+.globl	_restgpr1_29
+_restgpr1_29:
+	ld	r0,16(r12)
+	ld	r29,-24(r12)
+	mtlr	r0
+	ld	r30,-16(r12)
+	ld	r31,-8(r12)
+	blr
+
+.globl	_restgpr1_30
+_restgpr1_30:
+	ld	r30,-16(r12)
+.globl	_restgpr1_31
+_restgpr1_31:
+	ld	r0,16(r12)
+	ld	r31,-8(r12)
+	mtlr	r0
+	blr
+
 #ifdef CONFIG_ALTIVEC
 /* Called with r0 pointing just beyond the end of the vector save area.  */
 
@@ -540,6 +662,128 @@  _restvr_31:
 
 #endif /* CONFIG_ALTIVEC */
 
+#ifdef CONFIG_PPC_FPU
+
+.globl	_savefpr_14
+_savefpr_14:
+	stfd f14,-144(r1)
+.globl	_savefpr_15
+_savefpr_15:
+	stfd f15,-136(r1)
+.globl	_savefpr_16
+_savefpr_16:
+	stfd f16,-128(r1)
+.globl	_savefpr_17
+_savefpr_17:
+	stfd f17,-120(r1)
+.globl	_savefpr_18
+_savefpr_18:
+	stfd f18,-112(r1)
+.globl	_savefpr_19
+_savefpr_19:
+	stfd f19,-104(r1)
+.globl	_savefpr_20
+_savefpr_20:
+	stfd f20,-96(r1)
+.globl	_savefpr_21
+_savefpr_21:
+	stfd f21,-88(r1)
+.globl	_savefpr_22
+_savefpr_22:
+	stfd f22,-80(r1)
+.globl	_savefpr_23
+_savefpr_23:
+	stfd f23,-72(r1)
+.globl	_savefpr_24
+_savefpr_24:
+	stfd f24,-64(r1)
+.globl	_savefpr_25
+_savefpr_25:
+	stfd f25,-56(r1)
+.globl	_savefpr_26
+_savefpr_26:
+	stfd f26,-48(r1)
+.globl	_savefpr_27
+_savefpr_27:
+	stfd f27,-40(r1)
+.globl	_savefpr_28
+_savefpr_28:
+	stfd f28,-32(r1)
+.globl	_savefpr_29
+_savefpr_29:
+	stfd f29,-24(r1)
+.globl	_savefpr_30
+_savefpr_30:
+	stfd f30,-16(r1)
+.globl	_savefpr_31
+_savefpr_31:
+	stfd f31,-8(r1)
+	std r0, 16(r1)
+	blr
+
+.globl	_restfpr_14
+_restfpr_14:
+	lfd f14,-144(r1)
+.globl	_restfpr_15
+_restfpr_15:
+	lfd f15,-136(r1)
+.globl	_restfpr_16
+_restfpr_16:
+	lfd f16,-128(r1)
+.globl	_restfpr_17
+_restfpr_17:
+	lfd f17,-120(r1)
+.globl	_restfpr_18
+_restfpr_18:
+	lfd f18,-112(r1)
+.globl	_restfpr_19
+_restfpr_19:
+	lfd f19,-104(r1)
+.globl	_restfpr_20
+_restfpr_20:
+	lfd f20,-96(r1)
+.globl	_restfpr_21
+_restfpr_21:
+	lfd f21,-88(r1)
+.globl	_restfpr_22
+_restfpr_22:
+	lfd f22,-80(r1)
+.globl	_restfpr_23
+_restfpr_23:
+	lfd f23,-72(r1)
+.globl	_restfpr_24
+_restfpr_24:
+	lfd f24,-64(r1)
+.globl	_restfpr_25
+_restfpr_25:
+	lfd f25,-56(r1)
+.globl	_restfpr_26
+_restfpr_26:
+	lfd f26,-48(r1)
+.globl	_restfpr_27
+_restfpr_27:
+	lfd f27,-40(r1)
+.globl	_restfpr_28
+_restfpr_28:
+	lfd f28,-32(r1)
+.globl	_restfpr_29
+_restfpr_29:
+	ld r0, 16(r1)
+	lfd f29,-24(r1)
+	mtlr r0
+	lfd f30,-16(r1)
+	lfd f31,-8(r1)
+	blr
+.globl	_restfpr_30
+_restfpr_30:
+	lfd f30,-16(r1)
+.globl	_restfpr_31
+_restfpr_31:
+	ld r0, 16(r1)
+	lfd f31,-8(r1)
+
+#endif /* CONFIG_PPC_FPU */
+
 #endif /* CONFIG_PPC64 */
 
 #endif
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 267b9a0a3abc..153a163ba3f7 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -597,8 +597,12 @@  static int ignore_undef_symbol(struct elf_info *info, const char *symname)
 		/* Special register function linked on all modules during final link of .ko */
 		if (strstarts(symname, "_restgpr0_") ||
 		    strstarts(symname, "_savegpr0_") ||
+		    strstarts(symname, "_restgpr1_") ||
+		    strstarts(symname, "_savegpr1_") ||
 		    strstarts(symname, "_restvr_") ||
 		    strstarts(symname, "_savevr_") ||
+		    strstarts(symname, "_restfpr_") ||
+		    strstarts(symname, "_savefpr_") ||
 		    strcmp(symname, ".TOC.") == 0)
 			return 1;