On Tue, Jul 07, 2015 at 04:35:17PM -0700, Andy Lutomirski wrote: > On Tue, Jul 7, 2015 at 4:29 PM, Josh Poimboeuf <jpoim...@redhat.com> 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 <jpoim...@redhat.com> 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.ga31...@treble.redhat.com > > 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.)
I strongly doubt it would force frame pointer generation if -fomit-frame-pointer is set. But I'll verify :-) > >> > + > >> > + 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. Ah, nice idea. That might cover all the cases. I'll try it. > > > > > 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 :) Insightful or not, your comments have been very helpful! -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/