On Wed, Aug 31, 2022 at 04:38:02PM -0500, Peter Bergner wrote: > On 8/31/22 4:07 PM, Segher Boessenkool wrote: > > On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote: > >> 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? > > For linux64.h which is what I think the powerpc64-linux build will use, > we have: > > linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT > > Doing the macro expansion by hand into: > > set_masks = POWERPC_MASKS; > #ifdef OS_MISSING_POWERPC64 > if (OS_MISSING_POWERPC64) > set_masks &= ~OPTION_MASK_POWERPC64; > #endif > > > ...gives us: > > set_masks = POWERPC_MASKS; > if (!TARGET_64BIT) > set_masks &= ~OPTION_MASK_POWERPC64; > > So if we handled a -mpowerpc64 earlier on the command line and added > OPTION_MASK_POWERPC64 to our cpu mask, then a following -m32 use will > remove it here. > > So I mentioned doing: > > linux64.h: > - #define OS_MISSING_POWERPC64 !TARGET_64BIT > + #define OS_MISSING_POWERPC64 0 > > ...which disables the above code only for powerpc64-linux builds and doesn't > affect AIX, Darwin, BSD, etc. or a powerpc-linux build.
But it is incorrect as well. Instead, we should look if -mpowerpc64 is enabled explicitly, and not change it if so. > > The kernel has. But there are user space things (glibc) that haven't > > been fixed, and those are default as well. > > Sure, but someone who is using -m32 -mpowerpc64 should know that and > relying on a 32-bit glibc to save/restore the full 64-bit registers > is a user error in my book. If you're using -m32 -mpower64, you > better know what you are doing and the limitations you have to live under. Of course. But -mpowerpc64 can never be any kind of default for 32-bit Linux. Not indirectly either. Segher
