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

[Martin Jambor <mjambor@suse.cz>]

Hi,

On Tue, Dec 18 2018, Andi Kleen 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 "
>
> 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.

I agree, I originally thought the problem was something else.

Thanks for the clarification,

Martin