Thumb kprobe API. was Re: Determining an ARM CPU's architecture

[Nicolas Pitre]

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