Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
From: Timothy Pearson <tpearson@raptorengineering.com>
Date: 2024-02-12 17:47:09
----- Original Message -----
From: "Segher Boessenkool" <redacted>
To: "Timothy Pearson" <tpearson@raptorengineering.com>
Cc: "linuxppc-dev" <redacted>
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!
SegherInteresting, 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!