Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o
From: Josh Poimboeuf
Date: Tue Dec 18 2018 - 09:01:13 EST
On Tue, Dec 18, 2018 at 01:15:40PM +0100, Martin Jambor wrote:
> OK, I have read through it and with the caveats that I don't quite
> understand what the failure is, that also believe attribute noclone
> should not affect frame pointer generation, and that I don't quite get
> how LTO comes into play, my comments are the following:
>
> I am the developer who introduced attribute noclone to GCC and also the
> one who advises against using it :-) ...at least without also using the
> noinline attribute, the combination means "I want only one or zero
> copies of this function in the compiled assembly" which you might need
> if you do fancy stuff in inline assembly, for example.
>
> I believe that when people use noclone on its own, in 99 out 100 cases
> they actually want something else. Usually there is something that
> references the function from code (such as assembly) or a tool that the
> compiler does know about and then they should use the "used" attribute.
> That is what I understood to be the use case here and therefore I
> recommended it. In other cases people want all inter-procedural (IPA)
> analyses to stay away from a function and then they should use attribute
> noipa (or in older GCCs, the combination of noinline and noclone).
>
> The attribute was introduced because it is useful in GCC testsuite, and
> although I think occasions when it is useful on its own elsewhere are
> very rare and quite obscure, they can happen. But it really only means
> you want only one or zero *non-inlined* copies of the function. For
> example if you have an asm in it that must appear in the compiled
> assembly only once but you are confident it will be optimized out in
> inlined instances. Or if you play games with __builtin_return_address()
> and somehow have a very clear idea what the return values should be.
>
> I'm afraid I cannot give an opinion what you should do in this case
> without understanding the problem better. If you can isolate the case
> where noclone behaves weirdly into a self-contained testcase, I'd be
> happy to have a look at it.
I whittled it down to a small test case. It turns out the problem is
caused by the "__optimize__("no-tracer")" atribute, which is used by our
__noclone macro:
# if __has_attribute(__optimize__)
# define __noclone __attribute__((__noclone__, __optimize__("no-tracer")))
# else
# define __noclone __attribute__((__noclone__))
# endif
Here's the test case. Notice it skips the frame pointer setup before
the call to __sanitizer_cov_trace_pc():
$ cat test.c
__attribute__((__optimize__("no-tracer"))) int test(void)
{
return 0;
}
$ gcc -O2 -fno-omit-frame-pointer -fsanitize-coverage=trace-pc -c -o test.o test.c
$ objdump -dr test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <test>:
0: 48 83 ec 08 sub $0x8,%rsp
4: e8 00 00 00 00 callq 9 <test+0x9>
5: R_X86_64_PC32 __sanitizer_cov_trace_pc-0x4
9: 31 c0 xor %eax,%eax
b: 48 83 c4 08 add $0x8,%rsp
f: c3 retq
It works if you remove the function attribute:
0000000000000000 <test>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: e8 00 00 00 00 callq 9 <test+0x9>
5: R_X86_64_PC32 __sanitizer_cov_trace_pc-0x4
9: 31 c0 xor %eax,%eax
b: 5d pop %rbp
c: c3 retq
Apparently we are using "no-tracer" because of:
commit 95272c29378ee7dc15f43fa2758cb28a5913a06d
Author: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Date: Thu Mar 31 09:38:51 2016 +0200
compiler-gcc: disable -ftracer for __noclone functions
-ftracer can duplicate asm blocks causing compilation to fail in
noclone functions. For example, KVM declares a global variable
in an asm like
asm("2: ... \n
.pushsection data \n
.global vmx_return \n
vmx_return: .long 2b");
and -ftracer causes a double declaration.
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: Michal Marek <mmarek@xxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
Cc: kvm@xxxxxxxxxxxxxxx
Reported-by: Linda Walsh <lkml@xxxxxxxxx>
Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
--
Josh