This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: uprobes and empty functions
On Thu, 2010-11-04 at 11:25 -0700, Jim Keniston wrote:
...
>
> But I think calls and jumps (conditional and unconditional) all have
> versions that take 32-bit displacements, so I think that in all cases
> you could achieve the desired effect by altering the displacement.
> I.e., the SSOL area is always close enough. (In some cases -- e.g.,
> opcodes eb and 70-7f -- the instruction takes a 1-byte displacement, so
> your substitute instruction would have to be longer than the original;
> but that's no big deal because there'd be no post-single-step fixup of
> the ip anyway.)
BTW, a complication to using ip-relative calls and jumps for your
substitute instructions is that (unlike in kprobes) probepoints can
steal each other's SSOL slots. So a probepoint may use different slot
addresses at different times, and the substitute instruction's
displacement field would have to be adjusted accordingly. And of course
you don't know the slot address when the probepoint is registered.
One possibility is for uprobe_take_insn_slot(), which populates the slot
(see call to access_process_vm), to delegate that step to an
arch-specific function.
>
> Other possibilities:
> For ip-relative calls and unconditional jumps, you could do what we do
> with x86_64 rip-relative instructions: convert them to indirect
> calls/jumps through a scratch register (which we save before
> single-stepping and restore afterward). Conditional jumps are another
> matter: they have no indirect versions, just ip-relative. But now that
> uprobes has a uprobe_emulate_insn() hook, you could emulate jumps.
>
> >
> > I understand you're no longer working in this area, so thanks for your
> > input so far! Glad we could keep you interested... ;)
> >
> > Josh
>
> Jim
Jim