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.)
>> > +
>> > + 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 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/
