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@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.
- 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.
- 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.