> > So the answer I picked _was_ to do more of it in Lua and OP_HALT was what made that viable...
> Interesting. Though I'll admit, I'm having a hard time reading between the lines here to figure out
> just what you did to implement this "manual instrumentation" method.
The breakpoints we set (via OP_HALT) call into our debugging mechanism when hit, but they can have a Lua callback associated with them which determines whether to stop (to support conditional breakpoints) and can run arbitrary code (to log, take measurements, etc). We already had debugger UI for configuring these kinds of breakpoints, so I just used that instead of defining a new low level breakpoint type.
The truly manual way to do this is basically "printf profiling" where actual code is inserted. Using code/conditional/logging breakpoints also it to be done more dynamically, but still provides full manual control over the nature of the instrumentation.
> In my own (far less sophisticated) experiments with instrumentation, I've quickly come to similar
> high-level conclusion. What one seems to need are multiple, complimentary tools ...
> ...both techniques have their drawbacks, but, they're also synergistic.
Yeah, definitely sounds like we arrived at a similar perspective.
> Thanks again for your replies Dan, it's been fascinating to learn a bit about how these issues played out in the context of a bigger project.
Sure thing. Happy to share.
DT
Hi,
Cheers,
Russ
