On Thu, 2010-12-16 at 15:29 +0530, Srikar Dronamraju wrote:
> Uprobes needs to maintain some task specific information include if a
> task is currently uprobed, the currently handing uprobe, any arch
> specific information (for example to handle rip relative instructions),
> the per-task slot where the original instruction is copied to before
> single-stepping.

This can go away once you have per-task xol slots and boosted probes,
because then you can write the complete replacement sequence on trap and
never need to come back until you hit another probe, right?

So xol_vaddr is the start of the xol slot,
vaddr is the trap address, we store those so that you still have the
state during the single-step things?

I guess you could obtain the xol slot information from the IP during
single-step, but since you have storage anyway, this might be cheaper.

And the active_probe is again due to single-step, right? Why exactly do
you need that? If you trap, acquire a new slot, write the replacement
sequence, single step through it, and release the slot once you're back
to the original code stream. I'm not quite seeing where you need the
probe during stepping.

Ah, I think I found it while reading patch 13, you need the pre/post_xol
callbacks, can't you simply synthesize their effect into the replacement
sequence?

push %rax
mov $vaddr, %rax
$INSN
pop %rax
jmp $next_insn

like replacements would obviate the need for the pre/post callbacks and
allow you to run straight through.

It doesn't look too hard to create simple sequences for each
UPROBE_FIX_* thingy: