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 <seg...@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
