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> 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. For more options, visit https://groups.google.com/d/optout.
