From: Martin Jambor <mjambor@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Miroslav Benes <mbenes@suse.cz>, Andi Kleen <ak@linux.intel.com>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"the arch\/x86 maintainers" <x86@kernel.org>
Subject: Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o
Date: Wed, 19 Dec 2018 18:31:15 +0100 [thread overview]
Message-ID: <ri6y38lo23g.fsf@suse.cz> (raw)
In-Reply-To: <20181218140105.ajuiglkpvstt3qxs@treble>
Hi,
On Tue, Dec 18 2018, Josh Poimboeuf wrote:
> On Tue, Dec 18, 2018 at 01:15:40PM +0100, Martin Jambor wrote:
>> 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:
Wonderful, thanks a lot.
>
> # 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
Well, it might not be intuitive but the __optimize__ attribute resets to
-O2 optimization defaults and thus drops -fno-omit-frame-pointer on the
floor, so no wonder there is no frame pointer. This applies to other
optimization options you pass on the command line, for example if you
still compile kernel with -fno-strict-aliasing, you get GCC assuming
strict aliasing in functions marked with your __noclone.
> Apparently we are using "no-tracer" because of:
>
>
> commit 95272c29378ee7dc15f43fa2758cb28a5913a06d
> Author: Paolo Bonzini <pbonzini@redhat.com>
> 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.
There is no way for a user to reliably prevent a duplication of an
inline assembly statement. The correct fix is to move such statements
to an assembly files. You have disabled tracer which duplicated it in
your case but other passes might do that too in the future.
The correct fix is to put such assembler snippets into separate assembly
files or, if you for for some reason insist on inline assembly, to use
'%=' inline assembler template format string (it is expanded to a number
that is unique in a compilation unit).
Martin
next prev parent reply other threads:[~2018-12-19 17:31 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-16 18:33 objtool warnings for kernel/trace/trace_selftest_dynamic.o Arnd Bergmann
2018-12-17 17:39 ` Josh Poimboeuf
2018-12-17 18:04 ` Andi Kleen
2018-12-17 18:16 ` Josh Poimboeuf
2018-12-17 19:29 ` Peter Zijlstra
2018-12-17 20:55 ` Andi Kleen
2018-12-17 22:35 ` Peter Zijlstra
2018-12-17 23:59 ` Andi Kleen
2018-12-18 9:19 ` Peter Zijlstra
2018-12-18 21:22 ` Andi Kleen
2018-12-17 21:31 ` Josh Poimboeuf
2018-12-17 22:36 ` Steven Rostedt
2018-12-18 0:06 ` Andi Kleen
2018-12-18 2:49 ` Josh Poimboeuf
2018-12-18 4:22 ` Andi Kleen
2018-12-18 9:28 ` Miroslav Benes
2018-12-18 12:15 ` Martin Jambor
2018-12-18 12:31 ` Steven Rostedt
2018-12-18 14:01 ` Josh Poimboeuf
2018-12-18 21:20 ` Andi Kleen
2018-12-19 3:44 ` Sean Christopherson
2018-12-19 17:31 ` Martin Jambor [this message]
2018-12-18 21:15 ` Andi Kleen
2018-12-18 21:57 ` Steven Rostedt
2018-12-18 22:13 ` Andi Kleen
2018-12-18 22:16 ` Steven Rostedt
2018-12-18 23:26 ` Andi Kleen
2018-12-18 23:40 ` Steven Rostedt
2018-12-19 17:38 ` Martin Jambor
2018-12-18 3:05 ` Josh Poimboeuf
2018-12-17 23:54 ` Andi Kleen
2018-12-17 21:03 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ri6y38lo23g.fsf@suse.cz \
--to=mjambor@suse.cz \
--cc=ak@linux.intel.com \
--cc=arnd@arndb.de \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.