[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABCJKucLewqpZjckFy4mptUq4k_O75ce7f8MXzqoERXGs9UUVg@mail.gmail.com>
Date: Wed, 21 Aug 2024 08:06:05 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Mark Rutland <mark.rutland@....com>,
Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>, linux-kernel@...r.kernel.org,
clang-built-linux <llvm@...ts.linux.dev>, Nathan Chancellor <nathan@...nel.org>
Subject: Re: [BUG] tracing: dynamic ftrace selftest detected failures
On Tue, Aug 20, 2024 at 5:21 PM Masami Hiramatsu <mhiramat@...nel.org> wrote:
>
> On Wed, 21 Aug 2024 08:43:51 +0900
> Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
>
> > On Tue, 20 Aug 2024 18:11:09 -0400
> > Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > > On Wed, 21 Aug 2024 07:05:39 +0900
> > > Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
> > >
> > >
> > > > Does the noinline attribute prevent embedding callsite too? I mean
> > > >
> > > > extern callee()
> > > >
> > > > noinline callee()
> > > > {
> > > > ...
> > > > }
> > > >
> > > > caller()
> > > > {
> > > > callee() // (*)
> > > > }
> > > >
> > > > In this case, does noinline prevent LTO to embed the callee at the callsite(*)
> > > > or prevent LTO remove the callee() symbol?
> > > >
> > >
> > > Even though we have it passed as a parameter, I think the compiler and
> > > linker is smart enough to see that and notice its use, and that the
> > > function passed in is a nop, which doesn't break the flow.
> > >
> > > Can you add the __used and see if it fixes it?
> >
> > Adding __used to DYN_FTRACE_TEST_NAME() and DYN_FTRACE_TEST_NAME2() does
> > not change, the test still fails. Hmm, what about makes the caller
> > (trace_selftest_startup_dynamic_tracing()) called via a function pointer?
> > In that case, wouldn't it be subject to constant propagetion?
> >
> > Let me try.
>
> OK, it is succeeded! Calling `caller` via global function pointer makes
> it run as we expected. It passed the dynamic_ftrace test, but other tests
> still fails. Those need to be called via function pointer too.
I was able to reproduce this with LTO_CLANG_FULL, and it indeed
optimizes away the direct calls to the empty stubs, but the functions
are still there. LTO_CLANG_THIN doesn't perform this optimization,
presumably because it doesn't have full visibility to the other TU.
Sami
Powered by blists - more mailing lists