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.
> 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.
Peter
