Thumb kprobe API. was Re: Determining an ARM CPU's architecture
nicolas.pitre at linaro.org
Wed Jul 6 18:52:09 UTC 2011
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.
More information about the linaro-kernel