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

[Dave Martin]

On Wed, Jul 06, 2011 at 01:38:44PM +0100, Tixy wrote:
> On Tue, 2011-07-05 at 14:46 +0100, Dave Martin wrote:
> > On Tue, Jul 5, 2011 at 12:35 PM, Tixy <tixy at 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.
> 
> Now we decided that we wouldn't support probing ARM code on Thumb
> kernels I've been changing the code to ignore bit 0 of the probe
> address. However, one problem with this is that the address is used by
> the non-arch specific framework code to identify probes.
> 
> This causes two problems.
> 
> 1. In the ARM kprobe_handler I have to decide whether to call get_kprobe
> with an address which has bit 0 set or not, which I can't do without
> knowing how the probe was originally registered. And doing a second
> lookups if the first fails seems too horrible.

You could maybe canonicalise all the addresses when registering
probes -- i.e., clear bit 0.  This avoids the problems which result from
abusing an address bit to store metadata -- providing there is somewhere
else we can store that arch-specific metadata for each registered probe.

Or is the whole registering process handled by generic code?

If so, and if there is no arch-specific hook, that might be considered
a deficiency in the generic code, though I'm not sure if this metadata
requirement would affect many architectures.

Having a probe simultaneously on overlapping ARM and Thumb locations
will not work in any case, so it may make little sense to worry about
matching to the correct probe if such an ambiguity occurs.  Really,
we should avoid overlapping probes being registered in the first place,
or just consider that to be user error.  In practice, I don't expect
this is likely to cause us any problems.

> 2. The generic kprobes code supports the case where two or more probes
> are placed at the same location, this will fail if bit 0 of the address
> differs.
> 
> I think therefore, that we should keep my original implementation where:
> 
> Probe addresses in thumb code must have bit 0 set. This will naturally
> be the case when using symbol lookup or "&function" to set a probe at
> the start of a function. It will also be the case for setting a probe in
> the middle of a function if the offset parameter is used for this. Other
> uses which calculate addresses by other means may need to be modified to
> set bit zero accordingly.
> 
> Does this sound reasonable?

It seems reasonable for the interface to require that probes should be set
in a consistent way -- so that all Thumb probes have to have bit 0 set
(from which it follows that two Thumb probes set in the same place will
match on the registered probe address).

I don't actually know whether there are any scenarios in which kprobes
would not naturally get registered in this way.  If registered probe is
based somehow off a link-time vmlinux or module symbol, bit 0 will
naturally be set and there's no problem.  "Other uses" would encompass
registering probes on arbitrary absolute addresses, which seems a bit
tenuous in any case.

Cheers
---Dave