On Wed, Apr 10, 2019 at 5:27 PM vaastav anand <vaastav.anan...@gmail.com> wrote: > > > That is the bare bones of the DWARF information. That will let you > read the DWARF info, but it won't help you map PC and SP values to > variable names. > > I am not sure why this is the case. I thought along with the dwarf info, once > I have the frame information for each goroutine's stack I could end up > mapping the values to the variables. This frame information is available from > runtime's Stack function in src/runtime/mprof.go > Maybe I missed something?
I was unclear. I don't mean that it can't be done. I mean that you will need a lot of code beyond what is provided by debug/dwarf. > > Correct. Heap variables don't have names at all in any case > > Ok, I am assuming anything on the heap is essentially referenced by the > pointer variable on the stack? Yes, or by a global variable, and possibly indirectly via other pointers. > Sorry, if the following is a stupid question : Do the global variables have > no name or is that something that is present in the debugging information? (I > used to think that the global variables would be somewhere in the code > segment and thus must have debugging info associated with it.) Global variable names should be present in the debug info. Ian -- 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.
