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

From: Andi Kleen
Date: Tue Dec 18 2018 - 16:15:05 EST

> 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 :-) least without also using the
> noinline attribute, the combination means "

The function in question uses noinline too.

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

For this case we only want one non inlined copy because it is used as a
test case for a function tracer.

LTO comes into play because it originally relied on being in a separate
file, so it would not be inlined, but with LTO that doesn't work.

> 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

AFAIK there is no noclone without noinline in the kernel tree.

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

Neither in the ftrace case, nor in the KVM case (another user which
has fancy inline assembly that cannot be duplicated) that's the case.
It's just about having exactly one out of line instance.

So based on that I think noclone is fine. Of course there
is still the open question why exactly the frame pointer disappears.