[PATCH 9/9] ARM: add uprobes support
Rabin Vincent
rabin at rab.in
Sun Oct 21 14:59:08 EDT 2012
On Mon, Oct 15, 2012 at 06:44:50PM +0100, Dave Martin wrote:
> On Mon, Oct 15, 2012 at 01:44:55PM +0200, Rabin Vincent wrote:
> > Why? It currently works for ARM userspace even if the kernel is
> > Thumb-2.
>
> My bad, I misread what was happening in the Makefile changes.
>
> My concern is about whether we can build the ARM and Thumb-2 kprobes
> code into the same kernel. If so, no problem, but I believe this is
> not a tested configuration for kprobes itself.
>
> If you've not already done so, it should be possible to test this
> by adding CONFIG_THUMB2_KERNEL=y to your config, providing your
> hardware is Thumb-2 capable.
I've tested this before. With a Thumb-2 kernel, both the kprobes test
(Thumb) and the uprobes test (ARM) run fine.
> General question which I'm not sure I understand yet: is is possible
> to combine uprobes/kprobes decode more completely? It's not obvious
> to me whether the uprobes-specific decoding only relates to features
> which architecturally execute differently in user mode versus
> privileged mode. Some explanation somewhere could be helpful.
What we change is not the decoding itself but the handling of the
instructions:
(1) Load and stores are executed from the xol area by user space so
the instructions need to be rewritten when they touch the PC. Kprobes
code rewrites the instructions directly and executes them or in some
cases simulates them.
(2) All other non-simulated instructions are also executed from the
XOL area in userspace. Because of this, the ALU instructions which
use the PC also need to be rewritten to not use the PC. Perhaps we
can actually get rid of this and just execute these instruction from
kernel space like it is done for uprobes.
So the uprobes code is uses the decoding tables just to know if the
instruction is using the PC or not, but if we make the ALU
instructions execute from kernel space we could actually use the
emulate_*() functions like kprobes does.
More information about the linux-arm-kernel
mailing list