On Tue, Jul 7, 2015 at 4:29 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > On Tue, Jul 07, 2015 at 03:57:14PM -0700, Andy Lutomirski wrote: >> On Tue, Jul 7, 2015 at 7:54 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: >> > >> > It currently only supports x86_64. I tried to make the code generic so >> > that support for other architectures can hopefully be plugged in >> > relatively easily. >> > >> > Currently with my Fedora config it's reporting over 1400 warnings, but >> > most of them are duplicates. The warnings affect 37 .c files and 18 .S >> > files. The C file warnings are generally due to inline assembly, which >> > doesn't seem to play nice with frame pointers. >> >> This issue might be worth bringing up on the gcc and binutils lists. >> If we need better toolchain support, let's ask for it. > > I think we found a good solution for this. See my update at: > > https://lkml.kernel.org/r/20150707223519.GA31294@xxxxxxxxxxxxxxxxx Does that force frame pointer generation? If so, then once we have a real kernel unwinder, we might want a non-frame-pointer-forcing version for better code generation. (That can wait, of course.) >> > + >> > + This is a context switch instruction like sysenter or sysret. Such >> > + instructions aren't allowed in a callable function, and are most >> > + likely part of kernel entry code. >> > + >> > + If the instruction isn't actually in a callable function, change >> > + ENDPROC to END. >> > + >> > + >> > +6. stackvalidate: asm_file.o: func()+0x26: jump to outside file from callable function >> > + or >> > + stackvalidate: asm_file.o: func()+0xd9: jump to dynamic address from callable function >> > + >> > + These are constraints imposed by stackvalidate so that it can >> > + properly analyze all jump targets. Dynamic jump targets and jumps to >> > + code in other object files aren't allowed. >> >> Does this not trigger due to optimized sibling calls to different files? > > This is a great point. With CONFIG_FRAME_POINTER it's not a problem, > because it adds -fno-optimize-sibling-calls. > > Without it, I think stackvalidate would spit out a ton of "jump to > outside file" warnings. > > I haven't yet looked at the details of how exactly sibling calls work. > I'd assume they're disabled because they break frame pointers somehow. > Any idea if they'd also break DWARF CFI stack traces? They'll certainly prevent unwinding from finding the pre-optimization caller, but the rest of unwinding should work. I don't know why we turn it off, though. You might want special-case jump-out-of-translation-unit to be okay if the stack frame is in its initial state. That is: func: jmp elsewhere could be considered okay, as could: func: push %rax pop %rax jmp elsewhere and similar. > > I probably need to do some digging there. If sibling calls don't break > CFI stack traces and we end up needing them, stackvalidate might need to > analyze the entire kernel image at once instead of its current per-.o > checking. > > Anyway, thanks a bunch for all your insightful feedback Andy! > I'm just pretending to be insightful :) --Andy -- 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
