Article on Sun's DTrace

Steven Smith sos22 at cantab.net
Mon Jul 12 11:08:20 PDT 2004


> >> > It's also possible to put probes on the return instruction of the
> >> > function.  I'm not sure how they're actually finding that, though.
> >> I think the return probe is done by adding a call probe that changes the 
> >> return address.
> > Yeah, I thought that when I first saw it, but the probe is passed the
> > address of the return instruction when it fires, and I can't see how
> > you could get that if it was just invoked by modifying the return
> > address on the call stack.
> Don't you think that they disassemble functions on-the-fly to find
> out prolog and return sequence of a function?
That is entirely plausible.

> On their DTrace support forum there is the article about the problem
> with different byte patterns of "movl %esp, %ebp" produced by
> different assemblers.
Do you have an URL for that?  I can't seem to find it.

> Also modifying functions on-the-fly require some sort of
> synchronization: noone should run function which currently is being
> modified (fbt provider).
I suspect that the actual probe trigger is an int3 instruction, rather
than a call, since that's a single byte and can therefore be
atomically copied in over the start of any instruction.  Any other
processor either sees the value before the probe was activated (which
is fine; it's just equivalent to the probe activating a split second
later) ot afterwards (which is also fine).  The x86 memory model is (I
think; someone with more knowledge may want to correct me) strong
enough to make that perfectly safe.

(So the push %ebp part of the prolog becomes an int3 instruction in a
single atomic operation, rather than just the first byte of a call
instruction).

I don't know enough about Sparcs to even speculate how it's done
there.

Steven.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040712/fd2f33ae/attachment.bin


More information about the freebsd-hackers mailing list