Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch V4 part 5 02/31] x86/entry: Provide helpers for execute on irqstack | Date | Wed, 06 May 2020 10:20:42 +0200 |
| |
Thomas Gleixner <tglx@linutronix.de> writes: > That also allows to move the xen hypercall extra magic code and the softirq > stack switching into C. > > The mechanism is straight forward: > > 1) Store the current stack pointer on top of the interrupt stack. That's > required for the unwinder. > > 2) Switch the stack pointer > > 3) Call the function > > 4) Restore the stackpointer > > The full code sequence to make the unwinder happy is: > > pushq %rbp > movq %rsp, %rbp > movq $(top_of_hardirq_stack - 8), %reg > movq %rsp, (%reg) > movq %reg , %rsp > call function > popq %rsp > leaveq > > While the following sequence would spare the 'popq %rsp': > > pushq %rbp > movq $(top_of_hardirq_stack - 8), %rbp > movq %rsp, (%rrbp) > xchgq %rbp, %rsp > call function > movq %rbp, %rsp > leaveq
So I stared some more into that.
The push rbp is wrong for the frame unwinder case. That one is happy (except for objtool) with the most minimalistic variant:
movq %%rsp, (%[tos]) movq %[tos], %%rsp call function popq %%rsp
which is not surprising because for the frame unwinder this is similar to the 'gcc aligns stack in the middle of the function' handling. BP still has to point to the previous frame. Adjustment of BP must only happen on function entry.
The stack border convention of having the pointer to the previous stack in the top word is sufficient for this.
objtool complains though:
warning: objtool: do_softirq_own_stack()+0x67: return with modified stack frame
That obviously makes also the ORC unwinder unhappty as objtool fails to provide the right hint. But also for ORC this construct should be completely sufficient.
I'm exploring another idea right now, but wanted to share the info.
Thanks,
tglx
| |