Thread (11 messages) 11 messages, 3 authors, 2024-02-13

Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

From: Timothy Pearson <tpearson@raptorengineering.com>
Date: 2024-02-12 18:07:51


----- Original Message -----
From: "Segher Boessenkool" <redacted>
To: "Timothy Pearson" <tpearson@raptorengineering.com>
Cc: "linuxppc-dev" <redacted>
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:
quoted
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?
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help