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

[Tixy]

On Wed, 2011-07-06 at 14:52 +0100, Dave Martin wrote:
> 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.
> 
> > 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.
> > 
> 
> 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?

It is handled by the 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.

I'm not worried about overlapping probes, it's about probing the same
Thumb location but where one user specifies bit 0 as set and the other
doesn't. Not very likely, admittedly.

-- 
Tixy