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

Timothy Pearson tpearson at raptorengineering.com
Tue Feb 13 05:07:03 AEDT 2024



----- Original Message -----
> From: "Segher Boessenkool" <segher at kernel.crashing.org>
> To: "Timothy Pearson" <tpearson at raptorengineering.com>
> Cc: "linuxppc-dev" <linuxppc-dev at 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.


More information about the Linuxppc-dev mailing list