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

Reply via email to