[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1456481658.25691.6.camel@ellerman.id.au>
Date: Fri, 26 Feb 2016 21:14:18 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Torsten Duwe <duwe@....de>
Cc: linuxppc-dev@...abs.org, bsingharora@...il.com,
linux-kernel@...r.kernel.org, rostedt@...dmis.org,
kamalesh@...ux.vnet.ibm.com, pmladek@...e.com, jeyu@...hat.com,
jkosina@...e.cz, live-patching@...r.kernel.org, mbenes@...e.cz
Subject: Re: [PATCH 04/12] powerpc/ftrace: Prepare for -mprofile-kernel
On Thu, 2016-02-25 at 14:52 +0100, Torsten Duwe wrote:
> On Thu, Feb 25, 2016 at 01:28:27AM +1100, Michael Ellerman wrote:
> > @@ -450,17 +448,44 @@ static unsigned long stub_for_addr(const Elf64_Shdr *sechdrs,
> > return (unsigned long)&stubs[i];
> > }
> >
> > +#ifdef CC_USING_MPROFILE_KERNEL
> > +static int is_early_mcount_callsite(u32 *instruction)
> > +{
> > + /* -mprofile-kernel sequence starting with
> > + * mflr r0 and maybe std r0, LRSAVE(r1).
> > + */
> > + if ((instruction[-3] == PPC_INST_MFLR &&
> > + instruction[-2] == PPC_INST_STD_LR) ||
> > + instruction[-2] == PPC_INST_MFLR) {
> > + /* Nothing to be done here, it's an _mcount
> > + * call location and r2 will have to be
> > + * restored in the _mcount function.
> > + */
> > + return 1;
> > + }
> > + return 0;
> > +}
> > +#else
>
> *You* said this might page fault :)
It does :) - I fixed it up in patch 6, sorry I realise that's hard to review.
> Did we agree yet whether we insist on a streamlined compiler?
> (GCC commit e95d0248dace required)?
No we didn't really. I think you're right that it's not /too/ hard to support
both sequences. But we may change our mind in future :)
cheers
Powered by blists - more mailing lists