On Mon, 4 Jul 2011, Tixy wrote:
On Mon, 2011-07-04 at 17:16 +0100, Dave Martin wrote:
On Sat, Jul 02, 2011 at 12:28:01PM +0100, Tixy wrote:
On Fri, 2011-07-01 at 19:26 +0100, Dave Martin wrote:
The interworking behaviour is uniform for ARMv5(T) and above, but since kernels built in Thumb cannot run on pre-v7, and kernels built in ARM cannot (or certainly should not) contain any Thumb code, these niceties may not matter.
Interworking in different on v7, ARM mode ALU instructions now interwork, e.g. "sub pc, pc, #3" will switch from ARM to Thumb.
OK, I was just thinking about Thumb, but this is a fair distinction.
Alternatively, would it make sense to oops instead if we discover when simulating the branch that it would try to switch to ARM?
I would think this can be determined at probe installation time.
I'm not sure I understand what you mean here. In ARM mode the instruction "sub pc, pc, #3" does the following
on ARMv7, switch to Thumb on ARMv6, stay in ARM mode on ARMv5 and earlier, UNPREDICTABLE so are you saying OOPS in the last case? (I currently have it staying ARM mode as I only distinguish between <=ARMv6 and >=ARMv7 )
Actually, is this something that may happen frequently? Given the behavior is not consistent, it is likely that no one will use such construct in practice and therefore we may consider simply refusing to install a probe on such instructions.
I was trying to say that if we already have code to handle cases of invalid instructions that the compiler/assembler would never generate, then we should have code to handle legal instructions that the the compiler/assembler won't generate because we're not building for Thumb.
Sure. If by that you mean properly refusing to handle them then I agree.
Before I started my work, the kprobes code already had a partial simulation of interworking, so someone else must have thought it worth while. Though it would obviously be a lot simpler if I could just wrap all interworking stuff up in #ifdef CONFIG_THUMB2_KERNEL.
Is it worth pinging the original committer to get his views on the rationale for this?
Over the weekend I implemented functions to check various interworking behaviour, and run these when kprobes is first initialised. So I now have things all simulated correctly and I think I may as well leave things in there now.
As long as this doesn't look like too much bloat then I agree.
Nicolas