[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