On Tue, Jul 5, 2011 at 12:35 PM, Tixy tixy@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