On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote: > On 8/31/22 2:28 PM, Segher Boessenkool wrote: > > On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote: > Right, but haven't the 64-bit Linux kernels been fixed forever to always > save/restore the full 64-bit hardware registers on a context switch/signal?
The kernel has. But there are user space things (glibc) that haven't been fixed, and those are default as well. > If not, them this whole thing is moot and the current behavior of disabling > -mpower64 if we use -m32 later on the command line is the correct thing to do. The kernel has no way of disabling -mpowerpc64. The instructions are valid on any CPU that supports them, whether SF=1 or SF=0. > > But we should not enable -mpowerpc64 on 32-bit Linux by default. > > I didn't imply we should do that. I was only agreeing with you that > we should try not disabling an explicit -mpowerpc64 when -m32 is used > later on the command line. Okay, glad we agree :-) > I only meant to say is that the code in rs6000_option_override_internal() is > what > seems to remove the OPTION_MASK_POWERPC64 from our cpu mask when -m32 is used > later on the command line... and that is controlled by OS_MISSING_POWERPC64. This is the default mask only here. > Changing OS_MISSING_POWERPC64 as I mentioned would not add > OPTION_MASK_POWERPC64 > to our cpu masks when -m32 is used. So you say this is where the bug is? Segher
