On Wed, 6 Jul 2011, Tixy wrote:
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.
Hmmm. Well, I think that simply trying it twice: first with the Thumb bit set if that is the most likely usage when they are recorded, and then without that bit, should be OK.
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?
I don't think it is right to change it as this would prevent deregistration as the kprobe user is likely to reuse the same address. Either a new per-architecture macro is introduced to canonicalize addresses, or we try to get away with calling get_kprobe() twice. I don't have a problem with the later either.
Nicolas