If you can't recompile the binary, an option is to use a generic dynamic instrumentation platform like DynamoRIO <https://github.com/DynamoRIO/dynamorio> (which I think works for Go programs after a recent bugfix). It works on windows, mac, and linux, and has been used in the past for various security-based testing and verification. Plenty of papers available on the website: http://dynamorio.org/pubs.html
On Thursday, November 15, 2018 at 3:06:11 PM UTC-8, Damian Gryski wrote: > > One approach would be to augment the compiler to instrument the binary > with the techniques outlined in: > > XRay: A Function Call Tracing System > https://ai.google/research/pubs/pub45287 > > Damian > > On Thursday, November 15, 2018 at 9:09:19 AM UTC-8, 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. For more options, visit https://groups.google.com/d/optout.
