(related to PR14701) It would be logical and nice to support timer.profile probes under the dyninst runtime. This requires investigation as to whether Dyninst has some kind of feature that allows triggering our handler at regular intervals proportionally to system tick, or whether we have to jury-rig the emulation in our own runtime.
I don't think Dyninst has anything like this, because we're talking about a "temporal" sort of instrumentation, rather than usual code locations. As for jury-rigging, the first question is whether to drive this from stapdyn or from within the mutatee. From within, we could possibly use posix timers in its signal mode, which will interrupt threads. I don't know any way to read the interrupted state, though, which defeats the purpose of timer.profile in the first place. I'm also hesitant to mess with target resources like signal handling. From the stapdyn mutator side, we could again use posix timers and then inject calls into the mutatee with Dyninst's oneTimeCode. We'd have to decide whether to broadcast to all mutatee threads, or just one at random. However, I don't think this approach will allow register state either. More brainstorming is welcome. We need to first discover some low-level mechanism that will even provide the state we want.