Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591469 > unrolled thread

Re: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv4] arm: ftrace: Adds support for  CONFIG_DYNAMIC_FTRACE_WITH_REGS Abel Vesa <abelvesa@gmail.com> - 2017-03-02 22:30 +0100
    Re: [PATCHv4] arm: ftrace: Adds support for  CONFIG_DYNAMIC_FTRACE_WITH_REGS Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-03 01:00 +0100

#1591469 — Re: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Tue, Feb 28, 2017 at 11:54:29AM +0000, Abel Vesa wrote:
> On Tue, Feb 28, 2017 at 11:46:38AM +0000, Russell King - ARM Linux wrote:
> > On Tue, Feb 28, 2017 at 11:22:27AM +0000, Abel Vesa wrote:
> > > On Tue, Feb 28, 2017 at 11:58:49AM +0100, Nicolai Stange wrote:
> > > > Hi Abel,
> > > > 
> > > > On Tue, Feb 28 2017, Abel Vesa wrote:
> > > > 
> > > > > On Mon, Feb 27, 2017 at 04:52:06PM +0100, Nicolai Stange wrote:
> > > > >> On Fri, Feb 24 2017, Abel Vesa wrote:
> > > > >> Wouldn't it be better (and more consistent with other archs) to have
> > > > >> 
> > > > >>   pt_regs->ARM_lr = original lr
> > > > >>   pt_refs->ARM_pc = current lr
> > > > >> 
> > > > >> instead?
> > > > 
> > > > The stack would look like this then
> > > > 
> > > > @ ...           | ARM_ip | ARM_sp | ARM_lr      | ARM_pc      | ...          |
> > > > @ 0  4          48       52       56            60            64    68       72
> > > > @ R0 | R1 | ... | LR     | SP + 4 | original LR | original PC | PSR | OLD_R0 | original LR |
Just to make sure we're on the same page. If we are replacing the LR 
with the original_LR is it worth keeping around the one pushed before 
the ftrace_regs_caller is called?

Another thing, PC needs to be new_LR and then we can restore all 
regs r0 through r15 like this:

	ldmia   sp, {r0-r15}
> > > > 
> > > > I.e. the pt_regs would capture almost the full context of the
> > > > instrumented function (except for ip).
> > > > 
> > > So basicly what you are saying is:
> > > - instead of current LR save original LR (previous one saved in instrumented function epilog)
> > > - instead of current PC save original PC (previous one saved in instrumented function epilog)
> > > 
> > > I still don't see the point of saving the actual value of PC since nobody will ever
> > > restore it. In case of livepatch it will get overwritten anyway. As for LR, I agree,
> > > it could be the original one in pt_regs.
> > > 
> > > I'll look into this sometime today or tomorrow and get back with updates.
> > 
> > Which is exactly what I proposed, with code, on one of the previous
> > iterations of this patch...
> Fair enough. I probably missunderstood your comments then.
> 
> Thanks.
> > 
> > -- 
> > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > according to speedtest.net.

[toc] | [next] | [standalone]

#1591565

On Thu, Mar 02, 2017 at 09:01:24PM +0000, Abel Vesa wrote:
> On Tue, Feb 28, 2017 at 11:54:29AM +0000, Abel Vesa wrote:
> > On Tue, Feb 28, 2017 at 11:46:38AM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Feb 28, 2017 at 11:22:27AM +0000, Abel Vesa wrote:
> > > > On Tue, Feb 28, 2017 at 11:58:49AM +0100, Nicolai Stange wrote:
> > > > > Hi Abel,
> > > > > 
> > > > > On Tue, Feb 28 2017, Abel Vesa wrote:
> > > > > 
> > > > > > On Mon, Feb 27, 2017 at 04:52:06PM +0100, Nicolai Stange wrote:
> > > > > >> On Fri, Feb 24 2017, Abel Vesa wrote:
> > > > > >> Wouldn't it be better (and more consistent with other archs) to have
> > > > > >> 
> > > > > >>   pt_regs->ARM_lr = original lr
> > > > > >>   pt_refs->ARM_pc = current lr
> > > > > >> 
> > > > > >> instead?
> > > > > 
> > > > > The stack would look like this then
> > > > > 
> > > > > @ ...           | ARM_ip | ARM_sp | ARM_lr      | ARM_pc      | ...          |
> > > > > @ 0  4          48       52       56            60            64    68       72
> > > > > @ R0 | R1 | ... | LR     | SP + 4 | original LR | original PC | PSR | OLD_R0 | original LR |
> Just to make sure we're on the same page. If we are replacing the LR 
> with the original_LR is it worth keeping around the one pushed before 
> the ftrace_regs_caller is called?
> 
> Another thing, PC needs to be new_LR and then we can restore all 
> regs r0 through r15 like this:
> 
> 	ldmia   sp, {r0-r15}

That's the intention - the point is to save the state as it was at the
point that the function was entered, not at the point when the ftrace
code was entered.  What we don't want is the implementation details of
GCC's mcount or ftrace's adaption of mcount being exposed via ftrace.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web