Re: v4.10: kernel stack frame pointer .. has bad value (null)

[Josh Poimboeuf]

On Mon, Mar 06, 2017 at 05:38:07PM +0100, Pavel Machek wrote:
> Sorry for the delay. This is on v4.11-rc1, but that should be similar.
> 
> pavel@duo:~$ gcc --version
> gcc (Debian 4.9.2-10) 4.9.2
> 
> And here's the disassemble:
> 
> c402d200 <start_secondary>:
> c402d200:       57                      push   %edi
> c402d201:       8d 7c 24 08             lea    0x8(%esp),%edi
> c402d205:       83 e4 f8                and    $0xfffffff8,%esp
> c402d208:       ff 77 fc                pushl  -0x4(%edi)
> c402d20b:       55                      push   %ebp
> c402d20c:       89 e5                   mov    %esp,%ebp
> c402d20e:       57                      push   %edi
> c402d20f:       56                      push   %esi
> c402d210:       83 ec 10                sub    $0x10,%esp

Thanks.  This confirms what I was thinking, the function prologue is
wack.  It's realigning the stack, but it's not the "normal" realign
pattern.  Instead it makes a fake frame header, which saves a duplicate
copy of the return address ("pushl -0x4(%edi)") in a place the unwinder
wasn't expecting.

I did some digging in gcc to figure out why this can happen.  gcc uses
something called a Dynamic Realign Argument Pointer (DRAP), which, when
enabled, makes a prologue like the above.  It's almost always enabled
for aligned stacks when -maccumulate-outgoing-args isn't set.

So I'm thinking we should have -maccumulate-outgoing-args always enabled
on x86_32 just like we already do on x86_64.

Can you verify the warning is fixed with the following patch?

-----

diff --git a/arch/x86/Makefile_32.cpu b/arch/x86/Makefile_32.cpu
index 6647ed4..53ec1e4 100644
--- a/arch/x86/Makefile_32.cpu
+++ b/arch/x86/Makefile_32.cpu
@@ -61,7 +61,7 @@ ifeq ($(CONFIG_JUMP_LABEL), y)
 ADD_ACCUMULATE_OUTGOING_ARGS := y
 endif
 
-cflags-$(ADD_ACCUMULATE_OUTGOING_ARGS) += $(call cc-option,-maccumulate-outgoing-args)
+cflags-y += $(call cc-option,-maccumulate-outgoing-args)
 
 # Bug fix for binutils: this option is required in order to keep
 # binutils from generating NOPL instructions against our will.