[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1602151351590.22727@cbobk.fhfr.pm>
Date: Mon, 15 Feb 2016 13:56:43 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Michael Ellerman <mpe@...erman.id.au>
cc: Torsten Duwe <duwe@....de>, Balbir Singh <bsingharora@...il.com>,
Miroslav Benes <mbenes@...e.cz>,
Petr Mladek <pmladek@...e.com>, Jessica Yu <jeyu@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
live-patching@...r.kernel.org
Subject: Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables
On Mon, 15 Feb 2016, Michael Ellerman wrote:
> > > > +echo "int func() { return 0; }" | \
> > > > + $* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
> > > > + sed -n -e '/func:/,/bl _mcount/p' | grep -q TOC
> > > > +
> > > > +leaf_toc_result=$?
> > >
> > > leaf_toc_result failed for me with gcc 5. I'll try and grab gcc-6
> > > and give the patches a spin
> >
> > Don't bother. _All_ gccs are broken in that respect currently.
>
> I'm not sure where we got our wires crossed on this one, but this is not a gcc
> bug. In fact it's a feature :)
>
> There is explicit code in gcc to check whether the TOC setup is needed and only
> emit it when it's required. One case where it's *not* required is when the
> function does not TOC accesses. (See rs6000_global_entry_point_needed_p()).
As gcc actually implements a '-mprofile-kernel' option, it's pretty much
aware of the fact that the inserted space will be used by the kernel for
inserting a call (as that's the sole point of the whole thing).
Therefore it must not consider any traceable function to be leaf (even
though it might "look" leaf from the source code); if it does, then the
mprofile-kernel option is useless.
So I actually would dare to call it a bug.
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists