[RFC] [PATCH 0/4] ARM: kprobes: Infrastructure to support probes in Thumb code

Nicolas Pitre nicolas.pitre at linaro.org
Mon Mar 21 22:37:51 UTC 2011


On Mon, 21 Mar 2011, Tixy wrote:

> On Mon, 2011-03-21 at 16:06 -0400, Nicolas Pitre wrote:
> > On Mon, 21 Mar 2011, Tixy wrote:
> > 
> > > On Mon, 2011-03-21 at 12:01 -0400, Nicolas Pitre wrote:
> > > > Why not always using a 16-bit Thumb breakpoint instruction even in place 
> > > > of a 32-bit Thumb instruction?  This way you sidestep all the issues 
> > > > about atomically updating the instruction across two words.  The 
> > > > instruction to emulate might still be 32-bit and therefore pc would be 
> > > > advanced appropriately.
> > > 
> > > If the breakpoint is in an IT block and its execution condition is false
> > > then the breakpoint may not cause an exception and the CPU will go on
> > > and try and execute the other half of the instruction.
> > 
> > yeah... bummer.
> > 
> > In this case this might be a worthwhile optimization to not do the heavy 
> > dance when the instruction is word aligned.
> 
> Is it worth adding extra code to optimise 50% of the cases? I've been
> assuming inserting and removing probes is a fairly heavyweight process
> anyway.

You don't need the big hammer for 16-bit insns either.

In the end it depends on how complex the extra code is.  If it is like

	if (!(addr & 2))
		goto skip;

then it might be worth it.  Of course this would look better as:

	if (insn_is_wide(insn) && addr & 2) {
		do_the_heavy_locking;
	}
	...


Nicolas



More information about the linaro-kernel mailing list