Determining an ARM CPU's architecture

[Dave Martin]

On Tue, Jul 5, 2011 at 12:35 PM, Tixy <tixy at yxit.co.uk> wrote:
> On Tue, 2011-07-05 at 12:01 +0100, Dave Martin wrote:
>> One question though -- how do we know when setting a probe whether the target
>> instruction is ARM or Thumb?
>
> I'm using the bottom bit of the probe address. The kprobes API lets you
> specify the probe location as a symbol
>
>        the_probe.symbol_name = "function_name";
>
> or as an address
>
>        the_probe.addr = &function_name;
>
> and both of these cases will work. If the address is obtained by another
> means which doesn't set bit zero to indicate thumb code, then it's going
> to go bang.

The only code locations which exist from the point of view of ELF are
function entry points, so the convention is clear for those.

The main other means I can think of is if people are setting ad-hoc
probes in the middle of functions.

Now, we could make correct setting of the Thumb bit part of the
semantics of the kprobes interface, but I think we have to document it
explicitly in that case, and there's a risk it could interfere with
some existing uses of kprobes.

If there is automatic infrastructure for creating probe points in the
middle of functions, this would also have to be careful to set the bit
correctly, since by default the noted locations may not have the bit
set correctly.  I forget exactly what such infrastructure may exist --
do you have ideas on this?

> Do you think that we should assume all probes are Thumb on Thumb kernels
> and ARM on ARM kernels? And therefore configure out ARM instruction
> decoding and simulation on Thumb kernels?

I'm starting to feel that it might be safer to assume everything is
Thumb -- since the overwhelming majority of the kernel is Thumb for a
Thumb kernel.  Literally just a handful of instructions will be ARM,
pretty much all of them in places where it would be impossible/unsafe
to set a kprobe anyway (such as the kernel entry point, low-level
power management backend code and the vectors page).

It's a bit annoying, since we can quite reasonably simulate this part
of the architecture in kprobes (as you do).  But it could create
problems which outweigh the usefulness.  That's just my gut feeling
though -- I don't have specific examples.  If you don't think my
concerns are likely to lead to actual problems, that's fair enough.

Cheers
---Dave