Ahh that makes sense thank you. I think this file in Delve : https://github.com/go-delve/delve/blob/master/pkg/proc/bininfo.go does exactly what I need if I am not wrong.
On Wednesday, 10 April 2019 21:04:49 UTC-7, Ian Lance Taylor wrote: > > On Wed, Apr 10, 2019 at 5:27 PM vaastav anand <vaastav...@gmail.com > <javascript:>> 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.
