On Wed, Jun 22, 2016 at 9:30 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > Andy, > > So I got a chance to look at this some more. I'm thinking that to make > this feature more consistently useful, we shouldn't only annotate > pt_regs frames for calls to handlers; other calls should be annotated as > well: preempt_schedule_irq, CALL_enter_from_user_mode, > prepare_exit_to_usermode, SWAPGS, TRACE_IRQS_OFF, DISABLE_INTERRUPTS, > etc. That way, the unwinder will always be able to find pt_regs from an > interrupt/exception, even if starting from one of these other calls. > > But then, things get ugly. You have to either setup and tear down the > frame for every possible call, or do a higher-level setup/teardown > across multiple calls, which invalidates several assumptions in the > entry code about the location of pt_regs on the stack. > Here's yet another harebrained idea. Maybe it works better than my previous harebrained ideas :) Your patch is already creating a somewhat nonstandard stack frame: + movq %rbp, 0*8(%rsp) + movq $entry_frame_ret, 1*8(%rsp) + movq %rsp, %rbp It's kind of a normal stack frame, but rbp points at something odd, and to unwind it fully correctly, the unwinder needs to know about it. What if we made it even more special, along the lines of: leaq offset_to_ptregs(%rsp), %rbp xorq $-1, %rbp IOW, don't write anything to the stack at all, and just put a special value into RBP that says "the next frame is pt_regs at such-and-such address". Do this once on entry and make sure to restore RBP (from pt_regs) on exit. Now the unwinder can notice that RBP has the high bits clear *and* that the negation of it points to the stack, and it can figure out what's going on. What do you think? Am I nuts or could this work? It had better not have much risk of breaking things worse than they currently are, given that current kernel allow user code to stick any value it likes into the very last element of the RBP chain. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
