> >> > 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.
pgpp87t1IesDg.pgp
Description: PGP signature
