Pike’s “coverage" uses source code rewriting and recompiling, so it is not dynamic instrumentation - at least how I would define it. Dynamic instrumentation to me means to instrument at runtime on an existing binary/distribution.
> On Nov 15, 2018, at 12:55 PM, Michael Jones <michael.jo...@gmail.com> wrote: > > You could study Rob Pike’s coverage/profiling tool to see how he adds and > exploits basic block counting. Good work as always. > > On Thu, Nov 15, 2018 at 9:34 AM Robert Engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > AFAIK dtrace support is compiled in. If not enabled there are some tricks to > make is essentially zero cost, but it is still there from the start. Could be > wrong but that’s my understanding. > > Sent from my iPhone > > On Nov 15, 2018, at 11:27 AM, Steven Hartland <ste...@multiplay.co.uk > <mailto:ste...@multiplay.co.uk>> wrote: > >> dtrace support? >> >> On 15/11/2018 16:51, ju...@sqreen.io <mailto:ju...@sqreen.io> wrote: >>> Hi, >>> >>> I am working on dynamic instrumentation of Go programs at run time, >>> possibly without static source-code instrumentation. As I would like a >>> solution as close to Go and standard as possible, I was first thinking of >>> using `go generate` to generate a file adding things `reflect` doesn't >>> provide such as the list of packages, functions, global variables... That >>> way, I should be able to use `reflect` to modify any dynamic calls by >>> modifying the method tables of their underlying type representations. >>> >>> But regarding statically linked calls, the less intrusive technique I found >>> are uprobes, which is linux-specific. And at the opposite, there are >>> user-space binary code instrumentation libraries such as dyninst that >>> modify the code at run time... >>> >>> So I am wondering if anyone here has any thoughts on this subject, that >>> doesn't seem to be solved for Go programs. >>> >>> Thanks! >>> >>> Julio >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts+unsubscr...@googlegroups.com >>> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > -- > Michael T. Jones > michael.jo...@gmail.com <mailto:michael.jo...@gmail.com> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
