Determining an ARM CPU's architecture
tixy at yxit.co.uk
Mon Jul 4 19:33:59 UTC 2011
On Mon, 2011-07-04 at 14:44 -0400, Nicolas Pitre wrote:
> > > 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.
It can't in the general case of data processing operations storing their
result to PC because it will depend on register contents at the time the
probe is hit. My example was bad because it only used PC and constants,
think of something different like "add pc, pc, r0"
> > 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.
It is consistent if the calculated address always aligned to a word. And
it is also very common with instructions like "mov pc, reg"
> > 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
Or by emulating them in exactly the same way as they normally execute on
> > > > 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.
74 lines, half of which are comments or blank. 48 bytes of code.
We've been talking about data-processing instructions but I've also done
similar for "ldr pc, [...]" as Arnd suggested that we might have single
kernel binaries that execute on both ARMv4 and v5 hardware.
More information about the linaro-kernel