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
Hi,
On Tue, Dec 18 2018, Josh Poimboeuf wrote:
> On Tue, Dec 18, 2018 at 01:15:40PM +0100, Martin Jambor wrote:
>> I'm afraid I cannot give an opinion what you should do in this case
>> without understanding the problem better. If you can isolate the case
>> where noclone behaves weirdly into a
+cc Nadav and Paolo
On Tue, Dec 18, 2018 at 01:20:42PM -0800, Andi Kleen wrote:
> > I whittled it down to a small test case. It turns out the problem is
> > caused by the "__optimize__("no-tracer")" atribute, which is used by our
> > __noclone macro:
> >
> >
> > # if
On Tue, 18 Dec 2018 15:26:36 -0800
Andi Kleen wrote:
> > I thought that someone said that "used" would also prevent inlining.
>
> that's not correct. You need noinline
Sure, whatever. That's besides the point.
The thing is, I don't need noclone. Just remove that and keep the
noiniline, and
On Tue, Dec 18, 2018 at 05:16:20PM -0500, Steven Rostedt wrote:
> On Tue, 18 Dec 2018 14:13:38 -0800
> Andi Kleen wrote:
>
> > > Again, that's not the ftrace case. It doesn't care about more than one
> > > out of line instance. Thus, for this particular use, "used" should be
> > > good enough.
On Tue, 18 Dec 2018 14:13:38 -0800
Andi Kleen wrote:
> > Again, that's not the ftrace case. It doesn't care about more than one
> > out of line instance. Thus, for this particular use, "used" should be
> > good enough.
>
> You mean noinline used?
I thought that someone said that "used"
On Tue, Dec 18, 2018 at 04:57:13PM -0500, Steven Rostedt wrote:
> Hmm, how does that work? When does LTO do its linker magic? Because the
> fentry/mcounts are added when the object is created. Are they removed
> if the compiler sees that it can be inlined? Or does LTO just compile
> everything in
On Tue, 18 Dec 2018 13:15:01 -0800
Andi Kleen 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 "
>
> The function in question
On Tue, Dec 18, 2018 at 10:19:32AM +0100, Peter Zijlstra wrote:
> On Mon, Dec 17, 2018 at 03:59:50PM -0800, Andi Kleen wrote:
> > BTW I have a user base for LTO and so far noone has reported any issues
> > like this.
>
> Because ordering issues are immediately obvious and easy to debug no
>
> I whittled it down to a small test case. It turns out the problem is
> caused by the "__optimize__("no-tracer")" atribute, which is used by our
> __noclone macro:
>
>
> # if __has_attribute(__optimize__)
> # define __noclone __attribute__((__noclone__,
>
> 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
On Tue, Dec 18, 2018 at 01:15:40PM +0100, Martin Jambor 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
On Tue, 18 Dec 2018 13:15:40 +0100
Martin Jambor 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
Hi,
On Tue, Dec 18 2018, Miroslav Benes wrote:
>> Sorry for suggesting this prematurely, my email client stopped syncing
>> and I missed your later replies to Peter about this.
>>
>> > > Should it be reverted, or just remove the noclone, and keep the
>> > > noinline?
>> >
>> > It should not be
On Mon, 17 Dec 2018, Josh Poimboeuf wrote:
> On Mon, Dec 17, 2018 at 04:06:18PM -0800, Andi Kleen wrote:
> > On Mon, Dec 17, 2018 at 05:36:44PM -0500, Steven Rostedt wrote:
> > > On Mon, 17 Dec 2018 15:31:26 -0600
> > > Josh Poimboeuf wrote:
> > >
> > > > On Mon, Dec 17, 2018 at 08:29:38PM
On Mon, Dec 17, 2018 at 03:59:50PM -0800, Andi Kleen wrote:
> BTW I have a user base for LTO and so far noone has reported any issues
> like this.
Because ordering issues are immediately obvious and easy to debug no
doubt.
> The plugin is only used for older versions of GCC. Newer versions have
> the same functionality builtin with -fsanitize-coverage=trace-pc.
Ok and the frame pointer issue is with the older version only?
>
> So the problem is GCC. We're using a function attribute which at least
> oneGCC
On Mon, Dec 17, 2018 at 05:36:44PM -0500, Steven Rostedt wrote:
> On Mon, 17 Dec 2018 15:31:26 -0600
> Josh Poimboeuf wrote:
>
> > On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> > > On Mon, Dec 17, 2018 at 12:16:38PM -0600, Josh Poimboeuf wrote:
> > >
> > > > > Yes LTO
On Mon, Dec 17, 2018 at 04:06:18PM -0800, Andi Kleen wrote:
> On Mon, Dec 17, 2018 at 05:36:44PM -0500, Steven Rostedt wrote:
> > On Mon, 17 Dec 2018 15:31:26 -0600
> > Josh Poimboeuf wrote:
> >
> > > On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Dec 17, 2018 at
On Mon, Dec 17, 2018 at 05:36:44PM -0500, Steven Rostedt wrote:
> On Mon, 17 Dec 2018 15:31:26 -0600
> Josh Poimboeuf wrote:
>
> > On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> > > On Mon, Dec 17, 2018 at 12:16:38PM -0600, Josh Poimboeuf wrote:
> > >
> > > > > Yes LTO
On Mon, Dec 17, 2018 at 11:35:24PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 17, 2018 at 12:55:35PM -0800, Andi Kleen wrote:
> > On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> > > When/if we get the LTO trainwreck sorted -- which very much includes
> > > getting that
On Mon, Dec 17, 2018 at 03:31:26PM -0600, Josh Poimboeuf wrote:
> On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> > On Mon, Dec 17, 2018 at 12:16:38PM -0600, Josh Poimboeuf wrote:
> >
> > > > Yes LTO causes the to be treated like static functions.
> > > >
> > > > I guess
On Mon, 17 Dec 2018 15:31:26 -0600
Josh Poimboeuf wrote:
> On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> > On Mon, Dec 17, 2018 at 12:16:38PM -0600, Josh Poimboeuf wrote:
> >
> > > > Yes LTO causes the to be treated like static functions.
> > > >
> > > > I guess noclone
On Mon, Dec 17, 2018 at 12:55:35PM -0800, Andi Kleen wrote:
> On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> > When/if we get the LTO trainwreck sorted -- which very much includes
> > getting that memory-order-consume fixed -- we can revisit all that.
>
> What do you mean? I'm
On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 17, 2018 at 12:16:38PM -0600, Josh Poimboeuf wrote:
>
> > > Yes LTO causes the to be treated like static functions.
> > >
> > > I guess noclone is unlikely to be really needed here because these
> > > functions are
> > That seems weird.
> >
> > Are you sure it's not just because they are empty? AFAIK
> > gcc doesn't necessarily generate frame pointers for empty functions.
>
> I suspected that it was because they're empty, however I didn't see this
> warning for other leaf functions. The sancov plugin is
On Mon, Dec 17, 2018 at 08:29:38PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 17, 2018 at 12:16:38PM -0600, Josh Poimboeuf wrote:
>
> > > Yes LTO causes the to be treated like static functions.
> > >
> > > I guess noclone is unlikely to be really needed here because these
> > > functions are
On Mon, Dec 17, 2018 at 12:16:38PM -0600, Josh Poimboeuf wrote:
> > Yes LTO causes the to be treated like static functions.
> >
> > I guess noclone is unlikely to be really needed here because these
> > functions are unlikely to be cloned.
> >
> > So as a workaround it could be removed.
> >
>
On Mon, Dec 17, 2018 at 10:04:34AM -0800, Andi Kleen wrote:
> On Mon, Dec 17, 2018 at 11:39:00AM -0600, Josh Poimboeuf wrote:
> > On Sun, Dec 16, 2018 at 07:33:11PM +0100, Arnd Bergmann wrote:
> > > Hi Josh,
> > >
> > > In randconfig tests with gcc-8.1, I get this warning every
> > > few hundred
On Mon, Dec 17, 2018 at 11:39:00AM -0600, Josh Poimboeuf wrote:
> On Sun, Dec 16, 2018 at 07:33:11PM +0100, Arnd Bergmann wrote:
> > Hi Josh,
> >
> > In randconfig tests with gcc-8.1, I get this warning every
> > few hundred builds, tried it on both next/master and 4.19.y-stable:
> >
> >
On Sun, Dec 16, 2018 at 07:33:11PM +0100, Arnd Bergmann wrote:
> Hi Josh,
>
> In randconfig tests with gcc-8.1, I get this warning every
> few hundred builds, tried it on both next/master and 4.19.y-stable:
>
> kernel/trace/trace_selftest_dynamic.o: warning: objtool:
>
Hi Josh,
In randconfig tests with gcc-8.1, I get this warning every
few hundred builds, tried it on both next/master and 4.19.y-stable:
kernel/trace/trace_selftest_dynamic.o: warning: objtool:
trace_selftest_dynamic_test_func()+0x5: call without frame pointer
save/setup
32 matches
Mail list logo
