Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o

[Andi Kleen]

On Mon, Dec 17, 2018 at 11:39:00AM -0600, Josh Poimboeuf wrote:
> On Sun, Dec 16, 2018 at 07:33:11PM +0100, Arnd Bergmann wrote:
> > Hi Josh,
> > 
> > In randconfig tests with gcc-8.1, I get this warning every
> > few hundred builds, tried it on both next/master and 4.19.y-stable:
> > 
> > kernel/trace/trace_selftest_dynamic.o: warning: objtool:
> > trace_selftest_dynamic_test_func()+0x5: call without frame pointer
> > save/setup
> > kernel/trace/trace_selftest_dynamic.o: warning: objtool:
> > trace_selftest_dynamic_test_func2()+0x5: call without frame pointer
> > save/setup
> > 
> > $ objdump -dr build/x86/0x90C84554_defconfig/kernel/trace/trace_selftest_dynamic.o
> > 
> > build/x86/0x90C84554_defconfig/kernel/trace/trace_selftest_dynamic.o:
> >    file format elf64-x86-64
> > 
> > Disassembly of section .text:
> > 
> > 0000000000000000 <trace_selftest_dynamic_test_func>:
> >    0:    e8 00 00 00 00           callq  5
> > <trace_selftest_dynamic_test_func+0x5>
> >             1: R_X86_64_PC32    __fentry__-0x4
> >    5:    e8 00 00 00 00           callq  a
> > <trace_selftest_dynamic_test_func+0xa>
> >             6: R_X86_64_PC32    __sanitizer_cov_trace_pc-0x4
> >    a:    31 c0                    xor    %eax,%eax
> >    c:    c3                       retq
> >    d:    0f 1f 00                 nopl   (%rax)
> > 
> > 0000000000000010 <trace_selftest_dynamic_test_func2>:
> >   10:    e8 00 00 00 00           callq  15
> > <trace_selftest_dynamic_test_func2+0x5>
> >             11: R_X86_64_PC32    __fentry__-0x4
> >   15:    e8 00 00 00 00           callq  1a
> > <trace_selftest_dynamic_test_func2+0xa>
> >             16: R_X86_64_PC32    __sanitizer_cov_trace_pc-0x4
> >   1a:    31 c0                    xor    %eax,%eax
> >   1c:    c3                       retq
> > 
> > I found this reported in
> > http://kisskb.ellerman.id.au/kisskb/buildresult/13499139/, but could
> > not find an existing fix or analysis.
> 
> Thanks for reporting this Arnd.
> 
> The problem is that, for some reason, __noclone is preventing GCC from
> creating frame pointers for these functions.  Miroslav said that

That seems weird. 

Are you sure it's not just because they are empty? AFAIK
gcc doesn't necessarily generate frame pointers for empty functions.

> __noclone is not recommended by GCC developers, and that __used can be
> used instead for the same purpose:
> 
>   https://lkml.kernel.org/r/alpine.LSU.2.21.1812171256390.3087@xxxxxxxxxxxxx
> 
> Andi,
> 
> is __noclone really needed here, since the functions aren't static?  Or
> does LTO cause them to be treated like static functions?

Yes LTO causes the to be treated like static functions.

I guess noclone is unlikely to be really needed here because these
functions are unlikely to be cloned.

So as a workaround it could be removed.

But note we have other noclone functions in the tree (like in KVM)
which actually need it.


-Andi