uretprobes/x86: hijack return address

Function to hijack the return address, replace it with a "trampoline"
and functio to predict the stack pointer address value at return.

Signed-off-by: Anton Arapov <anton@redhat.com>
Signed-off-by: Anithra P Janakiraman <anithra@linux.vnet.ibm.com>
uretprobes: trampoline implementation

The first time a uprobe with return consumer is hit for a process, a
trampoline slot is obtained in the xol_area and initialized with a
breakpoint instruction. This slot is subsequently used by all uretprobes.

Signed-off-by: Anton Arapov <anton@redhat.com>
Signed-off-by: Anithra P Janakiraman <anithra@linux.vnet.ibm.com>
uretprobes: return probe entry, prepare uretprobe

When a uprobe with return consumer is hit, prepare_uretprobe function is
invoked. It creates return_instance, hijacks return address and replaces
it with the trampoline.

This patch introduces return_consumer field in uprobe_task. It creates
additional overhead in filter_chain(), but this is the least evil at the
moment.

The other approach might be: use only consumers field for both probes and
return probes with additional flag introduction for distinguishing them.
This will remove the overhead in some functions like filter_chain(), however
it will comlicate handler_chain() and consumer_add()/_remove() routines.
And uprobes development moves towards reducing flags number so the field
can be removed eventually.

Signed-off-by: Anton Arapov <anton@redhat.com>
uretprobes: invoke return probe handlers

uretprobe handlers are invoked when the trampoline is hit, on completion
the trampoline is replaced with the saved return address and the uretprobe
instance deleted.

There are get stack pointer ( cur_sp = (unsigned long)regs->sp; ) and
restore ip (instruction_pointer_set(regs, orig_return_addr); ) in the
code, however I'm not sure if both is ok for any architecture and
perhaps should be moved to arch-dependent uprobes code otherwise.

Signed-off-by: Anton Arapov <anton@redhat.com>
uprobes: add bp_vaddr argument to consumer handler

Add argument to handler() to pass the breakpoint address(bp_vaddr). This makes
uprobes consistent, doesn't require users to calculate the pre-breakpoint
address themselves as well as remove uprobes.h import(see the cuts in
trace_event.c here). It also simplifies implementation of the return
probes(uretprobes).

I can't foresee whether anything else from the u[ret]probes should be exposed
the same way as breakpoint address and bet on it as unlikely, so I think
anything heavier than just a sufficient to pass an address variable is overkill.
Any input are welcome though.

Signed-off-by: Anton Arapov <anton@redhat.com>
uretprobes: register() and unregister() implementation

A uretprobe is specified by a file:offset:handler. A uprobe is created
at the offset specified. When this uprobe is hit a uretprobe instance
created and a probe placed instead of the return address of the current
function. The handler specified is invoked before replacing the return
address. A uretprobe therefore places two probes, firstly a uprobe at
offset, whose handler in turn places the second probe at the return
address at task runtime.

Signed-off-by: Anton Arapov <anton@redhat.com>