Ian, Can you give me more details about these terms: "g0", "systemstack", and "mcall"?
Robert: taking the trace route is incorrect for me; I am profiling, tracing is too expensive because of logging, furthermore, I don't want to recompile the application or change the go runtime. -Milind On Sat, Feb 9, 2019 at 2:34 PM Ian Lance Taylor <i...@golang.org> wrote: > On Sat, Feb 9, 2019 at 2:02 PM <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 > > 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? > > Yes, for amd64 all the goroutine switching code is in runtime/asm_amd64.s. > > > > 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? > > Yes, that is the standard idiom for switching goroutines, as seen in > the gosave, gogo, and mcall functions. Also systemstack arguably > changes goroutines, though only to the g0 of the current thread. > > The runtime does overwrite the PC in order to panic from a signal > handler, in sigctxt.preparePanic, but not for goroutine switching. > > As Robert Engels says, tracking traceGoStart might be useful, though > you do have to have tracing enabled. > > Ian (please reply to the mailing list, not just to me; thanks) > -- 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.
