You also need to look at internal/trace to see how the runtime logs the trace events related to the Go routines - that will show you where you need to intercept.
> On Feb 9, 2019, at 4:29 PM, robert engels <reng...@ix.netcom.com> wrote: > > It is runtime/trace/trace.go > > It is what is reported in the trace facility. It captures assigning Go > routines to OS thread (processor), and also switching Go routines on a > logical processor (OS thread). > > You will still need to use OS level facilities to determine the context > switches of the OS threads. > > The events are written to the trace file. You would need to modify the code > and build your own runtime if you wanted to perform live intercepts. > > >> On Feb 9, 2019, at 4:24 PM, Milind Chabbi <milis...@gmail.com >> <mailto:milis...@gmail.com>> wrote: >> >> Robert, >> Pointers to the exact file would be quite useful. Also, is it >> procedure-level or call-back level interception? >> I am looking at machine instruction-level interception. >> >> -Milind >> >> >> On Sat, Feb 9, 2019 at 2:17 PM robert engels <reng...@ix.netcom.com >> <mailto:reng...@ix.netcom.com>> wrote: >> It is slightly more advanced that that - since there are multiple OS threads >> that the Go routines are multiplexed onto. >> >> The easiest solution is to look at the ‘trace’ code as it records the >> context switches. >> >>> On Feb 9, 2019, at 3:34 PM, milis...@gmail.com <mailto:milis...@gmail.com> >>> wrote: >>> >>> I am looking at fine-grained calling context collection for go lang >>> programs (for all go routines) using binary instrumentation tools such as >>> Intel Pin. >>> In a traditional language such as C/C++ intercepting CALL/RET instructions >>> (plus some special handling for exceptions setjmp/longjmp) suffices. >>> Go makes it significantly more complicated. >>> >>> For Go, the scheduler can context switch from one goroutine to another >>> (including garbage collection etc.). >>> The scheduler adjusts the stack pointer and program counter during these >>> events, which (for x86) is mostly in this file: >>> https://github.com/golang/go/blob/master/src/runtime/asm_amd64.s >>> <https://github.com/golang/go/blob/master/src/runtime/asm_amd64.s> >>> Is there a go runtime expert, who can authoritatively confirm whether all >>> the go routine context switching code is captured in this file or if there >>> are other places too? >>> >>> It would also be great if somebody can confirm whether saving the current >>> go routine state into gobuf_sp, gobuf_pc, gobuf_g, gobuf_ctxt, gobuf_ret >>> and restoring a new one and jumping to the new gobuf_pc is the standard >>> context switching idiom? Is there use of any other idiom such as >>> overwriting the return address of a caller on the thread stack to jump to a >>> different context during a return from a procedure? >>> >>> Thanks in advance for answering these details. >>> -Milind >>> >>> -- >>> 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. For more options, visit https://groups.google.com/d/optout.
