On Wed, May 31, 2017 at 10:44 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > Add CFI hint undwarf annotations to entry_64.S. This will enable the > undwarf unwinder to unwind through any location in the entry code > including syscalls, interrupts, and exceptions. > > Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > --- > arch/x86/entry/Makefile | 1 - > arch/x86/entry/calling.h | 5 +++++ > arch/x86/entry/entry_64.S | 56 ++++++++++++++++++++++++++++++++++++++++++----- > 3 files changed, 55 insertions(+), 7 deletions(-) > > diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile > index 9976fce..af28a8a 100644 > --- a/arch/x86/entry/Makefile > +++ b/arch/x86/entry/Makefile > @@ -2,7 +2,6 @@ > # Makefile for the x86 low level entry code > # > > -OBJECT_FILES_NON_STANDARD_entry_$(BITS).o := y > OBJECT_FILES_NON_STANDARD_entry_64_compat.o := y > > CFLAGS_syscall_64.o += $(call cc-option,-Wno-override-init,) > diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h > index 05ed3d3..bbec02e 100644 > --- a/arch/x86/entry/calling.h > +++ b/arch/x86/entry/calling.h > @@ -1,4 +1,6 @@ > #include <linux/jump_label.h> > +#include <asm/undwarf.h> > + > > /* > Just to make sure I understand this, if we unwind from... > @@ -112,6 +114,7 @@ For 32-bit we have the following conventions - kernel is built with > movq %rdx, 12*8+\offset(%rsp) > movq %rsi, 13*8+\offset(%rsp) ...here..., will objtool think that rdx and rsi (etc) still live in their respective regs, or will it find them in the on-stack data given by CFI_REGS? If the former, how does undwarf deal with the corresponding pops? > movq %rdi, 14*8+\offset(%rsp) > + CFI_REGS offset=\offset extra=0 > @@ -414,6 +424,7 @@ ENTRY(ret_from_fork) > 2: > movq %rsp, %rdi > call syscall_return_slowpath /* returns with IRQs disabled */ > + CFI_REGS I'm confused. syscall_return_slowpath didn't change anything relevant to unwinding, right? What's CFI_REGS here for? -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
