From: Nathan Chancellor <nathan@kernel.org>
To: "René Rebe" <rene@exactco.de>
Cc: chleroy@kernel.org, linux-kbuild@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, maddy@linux.ibm.com,
mpe@ellerman.id.au, npiggin@gmail.com
Subject: Re: [PATCH V2] modpost: Amend ppc64 save/restfpr symnames for -Os build
Date: Mon, 2 Feb 2026 23:48:00 -0700 [thread overview]
Message-ID: <20260203064800.GA701088@ax162> (raw)
In-Reply-To: <20251123.162551.979799191208988118.rene@exactco.de>
On Sun, Nov 23, 2025 at 04:25:51PM +0100, René Rebe wrote:
> Hey,
>
> On Sun, 23 Nov 2025 16:09:41 +0100 (CET), René Rebe <rene@exactco.de> wrote:
>
> > On Sun, 23 Nov 2025 15:57:24 +0100, "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
> >
> > > Le 23/11/2025 à 13:13, René Rebe a écrit :
> > > > Building a size optimized ppc64 kernel (-Os), gcc emits more FP
> > > > save/restore symbols, that the linker generates on demand into the
> > > > .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c,
> > > > too. They are needed for the amdgpu in-kernel floating point support.
> > >
> > > Would have been interested to know with which version of GCC the
> > > problem started.
> >
> > idk, maybe forever, or at least a decade fo GCC? Most devs probably
> > don't build size optimized, and addtionally we only use in kernel
> > floating point for amdgpu since recently? Should I add Fixes: for the
> > in-kernel FP hash?
> >
> > > By the way you seem to fix the problem for modules, but does it also
> > > work when amdgpu is in kernel ? I would have expected a need to add
> > > functions in arch/powerpc/lib/crtsavres.S as well, just like following
> > > commits:
> > >
> > > 8fe9c93e7453 ("powerpc: Add vr save/restore functions")
> > > 7fca5dc8aa7a ("powerpc: Fix module building for gcc 4.5 and 64 bit")
> > > da3de6df33f5 ("[POWERPC] Fix -Os kernel builds with newer gcc
> > > versions")
> >
> > idk, I avoid linking that big stuff directly into the kernel and would
> > need to specically test that, too. I guess I go do that now, too, ...
>
> It appears built-in amdgpu FP somehow magically works for me:
>
> debug-linux:[linux-6.17]# grep DRM.*AMD .config
> CONFIG_DRM_AMDGPU=y
> CONFIG_DRM_AMDGPU_SI=y
> CONFIG_DRM_AMDGPU_CIK=y
> CONFIG_DRM_AMDGPU_USERPTR=y
> CONFIG_DRM_AMD_ACP=y
> CONFIG_DRM_AMD_DC=y
> CONFIG_DRM_AMD_DC_FP=y
> CONFIG_DRM_AMD_DC_SI=y
> ...
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_ddc.o
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_log.o
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_psp.o
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp.o
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp1_execution.o
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp1_transition.o
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp2_execution.o
> CC drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp2_transition.o
> AR drivers/gpu/drm/amd/amdgpu/built-in.a
> AR drivers/gpu/drm/built-in.a
> AR drivers/gpu/built-in.a
> AR drivers/built-in.a
> AR built-in.a
> AR vmlinux.a
> LD vmlinux.o
> GEN modules.builtin.modinfo
> GEN modules.builtin
> MODPOST vmlinux.symvers
> CC .vmlinux.export.o
> UPD include/generated/utsversion.h
> CC init/version-timestamp.o
> KSYMS .tmp_vmlinux0.kallsyms.S
> AS .tmp_vmlinux0.kallsyms.o
> LD .tmp_vmlinux1
> NM .tmp_vmlinux1.syms
> KSYMS .tmp_vmlinux1.kallsyms.S
> AS .tmp_vmlinux1.kallsyms.o
> LD .tmp_vmlinux2
> NM .tmp_vmlinux2.syms
> KSYMS .tmp_vmlinux2.kallsyms.S
> AS .tmp_vmlinux2.kallsyms.o
> LD vmlinux.unstripped
> NM System.map
> SORTTAB vmlinux.unstripped
> make[3]: Nothing to be done for 'vmlinux.unstripped'.
> OBJCOPY vmlinux
>
> So I guess the patch is good to go after clarifying which kind of
> Fixes: to use?
Was this ever picked up or addressed elswhere?
> > > > MODPOST Module.symvers
> > > > ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> > > > undefined!
> > > > WARNING: modpost: suppressed 56 unresolved symbol warnings because
> > > > there were too many)
> > > > Signed-off-by: René Rebe <rene@exactco.de>
> > > > ---
> > > > V2: description
> > > > Theoretically for -stable, but no previous commit that broke it.
> > >
> > > In that case you have to add Cc: stable@vger.kernel.org
> > > Add indeed it is likely a gcc upgrade that broke it, not a previous
> > > commit.
> >
> > Should I then simply use enabling amdgpu dc_fp and in-kernel FP as the
> > breaking commit for Fixes:?
> >
> > Thanks!
> >
> > René
> >
> > > > ---
> > > > scripts/mod/modpost.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> > > > index 47c8aa2a6939..133dfa16308a 100644
> > > > --- a/scripts/mod/modpost.c
> > > > +++ b/scripts/mod/modpost.c
> > > > @@ -602,6 +602,10 @@ 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, "_restfpr_") ||
> > > > + strstarts(symname, "_savefpr_") ||
> > > > strstarts(symname, "_restvr_") ||
> > > > strstarts(symname, "_savevr_") ||
> > > > strcmp(symname, ".TOC.") == 0)
> > >
> >
> > --
> > René Rebe, ExactCODE GmbH, Berlin, Germany
> > https://exactco.de • https://t2linux.com • https://patreon.com/renerebe
>
> --
> René Rebe, ExactCODE GmbH, Berlin, Germany
> https://exactco.de • https://t2linux.com • https://patreon.com/renerebe
next prev parent reply other threads:[~2026-02-03 6:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-23 12:13 [PATCH V2] modpost: Amend ppc64 save/restfpr symnames for -Os build René Rebe
2025-11-23 14:57 ` Christophe Leroy (CS GROUP)
2025-11-23 15:09 ` René Rebe
2025-11-23 15:25 ` René Rebe
2026-02-03 6:48 ` Nathan Chancellor [this message]
2026-02-03 9:18 ` René Rebe
2025-11-26 0:16 ` Erhard Furtner
2026-02-04 0:16 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260203064800.GA701088@ax162 \
--to=nathan@kernel.org \
--cc=chleroy@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=rene@exactco.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.