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
