On Mon, 1 Oct 2018 09:11:04 +0800 Bin Meng <bmeng...@gmail.com> wrote:
> Hi Nick, > > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npig...@gmail.com> wrote: > > > > On Sat, 29 Sep 2018 23:25:20 -0700 > > Bin Meng <bmeng...@gmail.com> wrote: > > > > > commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit > > > userspace to 512 bytes") only changes stack userspace redzone size. > > > We need increase the kernel one to 512 bytes too per ABIv2 spec. > > > > You're right we need 512 to be compatible with ABIv2, but as the > > comment says, gcc limits this to 288 bytes so that's what is used > > to save stack space. We can use a compiler version test to change > > this if llvm or a new version of gcc does something different. > > > > I believe what the comment says is for ABIv1. At the time when commit > 573ebfa6601f was submitted, kernel had not switched to ABIv2 build > yet. I see, yes you are right about that. However gcc still seems to be using 288 bytes. static inline bool offset_below_red_zone_p (HOST_WIDE_INT offset) { return offset < (DEFAULT_ABI == ABI_V4 ? 0 : TARGET_32BIT ? -220 : -288); } llvm does as well AFAIKS // DarwinABI has a 224-byte red zone. PPC32 SVR4ABI(Non-DarwinABI) has no // red zone and PPC64 SVR4ABI has a 288-byte red zone. unsigned getRedZoneSize() const { return isDarwinABI() ? 224 : (isPPC64() ? 288 : 0); } So I suspect we can get away with using 288 for the kernel. Although the ELFv2 ABI allows 512, I suspect at this point compilers won't switch over without an explicit red zone size flag. Thanks, Nick