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 |
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. |
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
----- 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!
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
----- 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!
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
----- 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.
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
----- 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. :(
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
----- 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 --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;