Hi Nick,
On Mon, Oct 1, 2018 at 10:23 AM Nicholas Piggin <npig...@gmail.com> wrote:
>
> 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 for the info of gcc/llvm codes. I suspect for the red zone size
gcc/llvm still uses ABIv1 defined value which is 288. If we get way
with kernel using 288, what's the point of having user as 512 (commit
573ebfa6601f)?
Regards,
Bin
