On Wed, 2011-07-06 at 13:21 -0400, Nicolas Pitre wrote:
On Wed, 6 Jul 2011, Tixy wrote:
On Wed, 2011-07-06 at 18:09 +0100, Dave Martin wrote:
Good point -- presumably the kprobes already refuses to set a probe if the target location already contains the opcode used for a kprobe trap?
It will do for ARM, because you're probing an undefined instruction. Other architecture can have optimised probes which use branches rather rather breakpoints.
The point is that we don't have to care about this case even if the generic kprobes code might be fooled by the same address presented with and without the Thumb bit since the second attempt will be refused and nothing nasty will occur.
That is true. So we've shot down point 2)
But we still have point 1) the ARM kprobe_handler has to to decide whether to call get_kprobe with an address which has bit 0 set or not.
If we aren't going to reject Thumb probes that are specified with bit 0 clear then the only cleanish option I can see is to add some new hook into the generic register_kprobe so we can modify this bit. However, who 'owns' the address value in the struct? This is set by the user of the API and currently left unchanged. Would it be acceptable for us to start changing it?