On 12 August 2016 at 09:28, Josh Poimboeuf <jpoim...@redhat.com> wrote: > The frame at the end of each idle task stack has a zeroed return > address. This is inconsistent with real task stacks, which have a real > return address at that spot. This inconsistency can be confusing for > stack unwinders. > > Make it a real address by using the side effect of a call instruction to > push the instruction pointer on the stack. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> > --- > arch/x86/kernel/head_64.S | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S > index 3621ad2..c90f481 100644 > --- a/arch/x86/kernel/head_64.S > +++ b/arch/x86/kernel/head_64.S > @@ -298,8 +298,9 @@ ENTRY(start_cpu) > * REX.W + FF /5 JMP m16:64 Jump far, absolute indirect, > * address given in m16:64. > */ > - movq initial_code(%rip),%rax > - pushq $0 # fake return address to stop unwinder > + call 1f # put return address on stack for unwinder > +1: xorq %rbp, %rbp # clear frame pointer > + movq initial_code(%rip), %rax > pushq $__KERNEL_CS # set correct cs > pushq %rax # target address in negative space > lretq
Josh, I have a couple of questions. It seems to me that this patch and the patch 16/51 are both aiming at the same thing, but are for two different architectures: 32-bit and 64-bit versions of x86. But you have taken slightly different approaches in the two patches (for 64-bit, we first jump and then make a function call, for 32-bit we directly call the function). Is there any particular reason for this? May be I missed out on something. Second, this is for the whole patch series. If I wanted to test this series, how should I go about doing so? Thanks Nilay
