[RFC] kprobes with thumb2 conditional code

[dave.martin@linaro.org (Dave Martin)]

On Wed, Jun 15, 2011 at 01:24:35PM +0100, Tixy wrote:
> On Wed, 2011-06-15 at 12:16 +0100, Dave Martin wrote:

[...]

> > Where branches appear in IT blocks, they're not allowed to be anywhere
> > except at the end of the block, so the next instruction is either outside
> > the block, or is an IT instruction itself (in which case we can still
> > set a probe on it).  In valid code there will always be a next instruction,
> > since the CPU will fall through the branch if the condition is false.
> 
> But, if we are asked to probe a normal unconditional branch, we don't
> know if its in an IT block or not. E.g. the branch instruction in this:
> 
> 	cmp	r1, #0
> 	itt	eq
> 	moveq	r0, #1
> 	beq	somewhere
> 	ldr	r0, [r1]
> 
> and in this:
> 
> 	mov	r0, #1
> 	b	somewhere
> 	.word	some_literal_pool_value
> 
> are the same instruction, the 'beq' syntax is just for readability.

Good point, I understand that those instructions are encoded the same, but
I hadn't considered the possibility that the following bytes will contain data
instead of instructions... though actually that will be common-ish after
unconditional branches.

Attempting to set a probe in data will of course be bad, since it may
lead to undetectable corruption.  Ugh.

(Hard to work around, unless you really want to implement full
instruction tracing or watchpoints.  OK, let's not do that! ;) 

> The real Thumb conditional branch instructions aren't allowed in IT
> blocks. It was when I implemented emulation of these that I began to
> have second thoughts about the approach to conditional instructions.
> 
> > That would deal with almost all cases, but it adds a bit of complexity
> > so I'm not convinced it's worth it.
> 
> Too complex to go there ;-)

Yup, I agree.

[...]

> > If you think that that #3 is not the simplest reasonable-looking
> > approach after all, then I guess we can think about alternatives.
> 
> I'm now convinced that #3 is best after all. It is the only thing we can
> get simple, consistent rules for. I.e.
> 
>         "Kprobes on conditional instructions don't trigger when the
>         condition is false. For conditional branches, this means that
>         they don't trigger in the branch not taken case."

Plus it's fairly striaghtforward to implement, so shouldn't waste effort.

As long as people don't get unpleasant surprises from setting a probe
on a function entry point, I think that's OK as an approach.

I think a real function generated by the compiler will never have a
conditional instruction at its entry point, since the ABI permits the
condition flags to be clobbered across procedure calls and returns
anyway... so the result of such an instruction would be indeterminate.
So a probe set on an external function label should always fire even
with the proposed implementation.

So #3 sounds good for me.

Cheers
---Dave