mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Martin Jambor <mjambor@suse.cz>
Cc: Miroslav Benes <mbenes@suse.cz>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andi Kleen <ak@linux.intel.com>,
	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: Tue, 18 Dec 2018 07:31:43 -0500	[thread overview]
Message-ID: <20181218073143.1536e8e9@vmware.local.home> (raw)
In-Reply-To: <ri6h8fbqbdf.fsf@suse.cz>

On Tue, 18 Dec 2018 13:15:40 +0100
Martin Jambor <mjambor@suse.cz> wrote:

> 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.

Sounds to me that we should not be using noclone in this instance.

> 
> 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.

With this explanation, I really believe the answer is s/noclone/used/.

Here's the problem that the "noinline noclone" is trying to solve. When
someone compiles with LTO (which links much more and can remove unused
functions, or inline them better) the ftrace dynamic self test
functions can be inlined. If that happens, they lose the
"mcount/fentry" from gcc -pg. Which was the reason they were made, and
placed in a separate file to begin with. Then when the self tests try
to enable function tracing on these functions, they can't and the boot
up tests fail, disabling ftrace.

The "noinline noclone" was added to prevent this case. And from your
description, it sounds like "noinline used" is what we actually want.

-- Steve

  reply	other threads:[~2018-12-18 12:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-16 18:33 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 [this message]
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
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=20181218073143.1536e8e9@vmware.local.home \
    --to=rostedt@goodmis.org \
    --cc=ak@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mjambor@suse.cz \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome