[PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets

[PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets

[Bin Meng]

The -mabi=elfv2 is currently specified twice in the makefile. Remove
the one that does not test compiler.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/powerpc/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 11a1acb..16b0695 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -93,7 +93,6 @@ ifdef CONFIG_PPC64
 cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= $(call cc-option,-mabi=elfv1)
 cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= $(call cc-option,-mcall-aixdesc)
 aflags-$(CONFIG_CPU_BIG_ENDIAN)		+= $(call cc-option,-mabi=elfv1)
-aflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -mabi=elfv2
 endif
 
 ifneq ($(cc-name),clang)
-- 
2.7.4

[PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Bin Meng]

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.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/powerpc/include/asm/ptrace.h | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 447cbd1..817be3f 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -30,16 +30,12 @@
 #ifdef __powerpc64__
 
 /*
- * Size of redzone that userspace is allowed to use below the stack
+ * Size of redzone that kernel/userspace is allowed to use below the stack
  * pointer.  This is 288 in the 64-bit big-endian ELF ABI, and 512 in
  * the new ELFv2 little-endian ABI, so we allow the larger amount.
- *
- * For kernel code we allow a 288-byte redzone, in order to conserve
- * kernel stack space; gcc currently only uses 288 bytes, and will
- * hopefully allow explicit control of the redzone size in future.
  */
 #define USER_REDZONE_SIZE	512
-#define KERNEL_REDZONE_SIZE	288
+#define KERNEL_REDZONE_SIZE	512
 
 #define STACK_FRAME_OVERHEAD	112	/* size of minimum stack frame */
 #define STACK_FRAME_LR_SAVE	2	/* Location of LR in stack frame */
-- 
2.7.4

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Nicholas Piggin]

On Sat, 29 Sep 2018 23:25:20 -0700
Bin Meng <bmeng.cn@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.

Thanks,
Nick

> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>  arch/powerpc/include/asm/ptrace.h | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index 447cbd1..817be3f 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -30,16 +30,12 @@
>  #ifdef __powerpc64__
>  
>  /*
> - * Size of redzone that userspace is allowed to use below the stack
> + * Size of redzone that kernel/userspace is allowed to use below the stack
>   * pointer.  This is 288 in the 64-bit big-endian ELF ABI, and 512 in
>   * the new ELFv2 little-endian ABI, so we allow the larger amount.
> - *
> - * For kernel code we allow a 288-byte redzone, in order to conserve
> - * kernel stack space; gcc currently only uses 288 bytes, and will
> - * hopefully allow explicit control of the redzone size in future.
>   */
>  #define USER_REDZONE_SIZE	512
> -#define KERNEL_REDZONE_SIZE	288
> +#define KERNEL_REDZONE_SIZE	512
>  
>  #define STACK_FRAME_OVERHEAD	112	/* size of minimum stack frame */
>  #define STACK_FRAME_LR_SAVE	2	/* Location of LR in stack frame */
> -- 
> 2.7.4
> 

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Bin Meng]

Hi Nick,

On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> On Sat, 29 Sep 2018 23:25:20 -0700
> Bin Meng <bmeng.cn@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.

Regards,
Bin

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Nicholas Piggin]

On Mon, 1 Oct 2018 09:11:04 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:

> Hi Nick,
> 
> On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > On Sat, 29 Sep 2018 23:25:20 -0700
> > Bin Meng <bmeng.cn@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

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Segher Boessenkool]

Hi!

On Mon, Oct 01, 2018 at 12:22:56PM +1000, Nicholas Piggin wrote:
> On Mon, 1 Oct 2018 09:11:04 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
> > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > Bin Meng <bmeng.cn@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.

And that is required by the ABI!

"""
2.2.2.4. Protected Zone

The 288 bytes below the stack pointer are available as volatile program
storage that is not preserved across function calls. Interrupt handlers and
any other functions that might run without an explicit call must take care
to preserve a protected zone, also referred to as the red zone, of 512 bytes
that consists of:

 * The 288-byte volatile program storage region that is used to hold saved
   registers and local variables
 * An additional 224 bytes below the volatile program storage region that is
   set aside as a volatile system storage region for system functions

If a function does not call other functions and does not need more stack
space than is available in the volatile program storage region (that is, 288
bytes), it does not need to have a stack frame. The 224-byte volatile system
storage region is not available to compilers for allocation to saved
registers and local variables.
"""

A routine has a red zone of 288 bytes.  Below there is 224 more bytes of
available storage, but that is not available to the routine itself: some
(asynchronous) other code (like an interrupt) can use (i.e. clobber) it.


Segher

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Nicholas Piggin]

On Mon, 1 Oct 2018 03:51:21 -0500
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> Hi!
> 
> On Mon, Oct 01, 2018 at 12:22:56PM +1000, Nicholas Piggin wrote:
> > On Mon, 1 Oct 2018 09:11:04 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:  
> > > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:  
> > > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > > Bin Meng <bmeng.cn@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.  
> 
> And that is required by the ABI!
> 
> """
> 2.2.2.4. Protected Zone
> 
> The 288 bytes below the stack pointer are available as volatile program
> storage that is not preserved across function calls. Interrupt handlers and
> any other functions that might run without an explicit call must take care
> to preserve a protected zone, also referred to as the red zone, of 512 bytes
> that consists of:
> 
>  * The 288-byte volatile program storage region that is used to hold saved
>    registers and local variables
>  * An additional 224 bytes below the volatile program storage region that is
>    set aside as a volatile system storage region for system functions
> 
> If a function does not call other functions and does not need more stack
> space than is available in the volatile program storage region (that is, 288
> bytes), it does not need to have a stack frame. The 224-byte volatile system
> storage region is not available to compilers for allocation to saved
> registers and local variables.
> """
> 
> A routine has a red zone of 288 bytes.  Below there is 224 more bytes of
> available storage, but that is not available to the routine itself: some
> (asynchronous) other code (like an interrupt) can use (i.e. clobber) it.

Thanks Segher, that explains it very well and shows we are safe with
288 in the kernel. So we can leave the code as-is, but the comment
could be updated.

What are "system functions" exactly? Can the kernel use that, or are
we talking about user mode system code like libraries? The kernel
could maybe use that for scratch space for synchronous interrupts to
avoid using a slow SPR for scratch.

Thanks,
Nick




> 
> 
> Segher

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Segher Boessenkool]

On Tue, Oct 02, 2018 at 09:59:29AM +1000, Nicholas Piggin wrote:
> On Mon, 1 Oct 2018 03:51:21 -0500
> Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > And that is required by the ABI!
> > 
> > """
> > 2.2.2.4. Protected Zone
> > 
> > The 288 bytes below the stack pointer are available as volatile program
> > storage that is not preserved across function calls. Interrupt handlers and
> > any other functions that might run without an explicit call must take care
> > to preserve a protected zone, also referred to as the red zone, of 512 bytes
> > that consists of:
> > 
> >  * The 288-byte volatile program storage region that is used to hold saved
> >    registers and local variables
> >  * An additional 224 bytes below the volatile program storage region that is
> >    set aside as a volatile system storage region for system functions
> > 
> > If a function does not call other functions and does not need more stack
> > space than is available in the volatile program storage region (that is, 288
> > bytes), it does not need to have a stack frame. The 224-byte volatile system
> > storage region is not available to compilers for allocation to saved
> > registers and local variables.
> > """
> > 
> > A routine has a red zone of 288 bytes.  Below there is 224 more bytes of
> > available storage, but that is not available to the routine itself: some
> > (asynchronous) other code (like an interrupt) can use (i.e. clobber) it.
> 
> Thanks Segher, that explains it very well and shows we are safe with
> 288 in the kernel. So we can leave the code as-is, but the comment
> could be updated.
> 
> What are "system functions" exactly?

That is an excellent question.  I think it was left vague on purpose?
"Stuff a user program cannot do itself", "ABI stuff", "whatever the OS
defines as system stuff"?

> Can the kernel use that, or are
> we talking about user mode system code like libraries? The kernel
> could maybe use that for scratch space for synchronous interrupts to
> avoid using a slow SPR for scratch.

If you're already using the kernel stack, sure.  When does this happen?


Segher

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Bin Meng]

Hi Nick,

On Mon, Oct 1, 2018 at 10:23 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> On Mon, 1 Oct 2018 09:11:04 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > Hi Nick,
> >
> > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> > >
> > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > Bin Meng <bmeng.cn@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

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Nicholas Piggin]

On Mon, 1 Oct 2018 20:41:19 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:

> Hi Nick,
> 
> On Mon, Oct 1, 2018 at 10:23 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > On Mon, 1 Oct 2018 09:11:04 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >  
> > > Hi Nick,
> > >
> > > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:  
> > > >
> > > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > > Bin Meng <bmeng.cn@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)?

See Segher's reply -- they are two different things here. 288 bytes is
the red zone that compilers may use. But there is another region out to
512 bytes which can be used by other system code (not compilers). So
the kernel always has to assume 512 for user.

The kernel code itself knows that it does not use any red zone beyond
288 bytes, so it does not have to preserve any more for its own stack.

Thanks,
Nick

Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes

[Segher Boessenkool]

On Sat, Sep 29, 2018 at 11:25:20PM -0700, Bin Meng wrote:
>  /*
> - * Size of redzone that userspace is allowed to use below the stack
> + * Size of redzone that kernel/userspace is allowed to use below the stack
>   * pointer.  This is 288 in the 64-bit big-endian ELF ABI, and 512 in
>   * the new ELFv2 little-endian ABI, so we allow the larger amount.
> - *
> - * For kernel code we allow a 288-byte redzone, in order to conserve
> - * kernel stack space; gcc currently only uses 288 bytes, and will
> - * hopefully allow explicit control of the redzone size in future.
>   */

Btw: patches welcome!  This will never be useful for userland code, so no
one in GCC land is looking at this (we did not even know it is wanted).


Segher

Re: [PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets

[Segher Boessenkool]

On Sat, Sep 29, 2018 at 11:25:19PM -0700, Bin Meng wrote:
> The -mabi=elfv2 is currently specified twice in the makefile. Remove
> the one that does not test compiler.

This was

ifdef CONFIG_PPC64
cflags-$(CONFIG_CPU_BIG_ENDIAN)         += $(call cc-option,-mabi=elfv1)
cflags-$(CONFIG_CPU_BIG_ENDIAN)         += $(call cc-option,-mcall-aixdesc)
aflags-$(CONFIG_CPU_BIG_ENDIAN)         += $(call cc-option,-mabi=elfv1)
aflags-$(CONFIG_CPU_LITTLE_ENDIAN)      += -mabi=elfv2
endif

and the later setting is

ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
AFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv2)
else
CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv1)
CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mcall-aixdesc)
AFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv1)
endif

Maybe these two pieces should be joined completely?


Segher

Re: [PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets

[Bin Meng]

On Mon, Oct 1, 2018 at 4:59 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sat, Sep 29, 2018 at 11:25:19PM -0700, Bin Meng wrote:
> > The -mabi=elfv2 is currently specified twice in the makefile. Remove
> > the one that does not test compiler.
>
> This was
>
> ifdef CONFIG_PPC64
> cflags-$(CONFIG_CPU_BIG_ENDIAN)         += $(call cc-option,-mabi=elfv1)
> cflags-$(CONFIG_CPU_BIG_ENDIAN)         += $(call cc-option,-mcall-aixdesc)
> aflags-$(CONFIG_CPU_BIG_ENDIAN)         += $(call cc-option,-mabi=elfv1)
> aflags-$(CONFIG_CPU_LITTLE_ENDIAN)      += -mabi=elfv2
> endif
>
> and the later setting is
>
> ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
> CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
> AFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv2)
> else
> CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv1)
> CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mcall-aixdesc)
> AFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv1)
> endif
>
> Maybe these two pieces should be joined completely?
>

Ah, yes! I was only looking at elfv2 stuff before :)

Regards,
Bin