> 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? > 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? 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.) PS Thanks so much for all the help! I really do appreciate it. On Wednesday, 10 April 2019 16:58:36 UTC-7, Ian Lance Taylor wrote: > > On Wed, Apr 10, 2019 at 4:34 PM vaastav anand <vaastav...@gmail.com > <javascript:>> wrote: > > > > Is the debug info exported in the binary in DWARF format? > > Yes. > > > And if so would this package work https://golang.org/pkg/debug/dwarf/? > > 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. > > > What about the global variables or the ones allocated on the heap? Are > they also not available inside the runtime either? > > Correct. Heap variables don't have names at all in any case. > > Ian > > > On Wednesday, 10 April 2019 13:28:49 UTC-7, Ian Lance Taylor wrote: > >> > >> On Tue, Apr 9, 2019 at 7:43 AM <vaastav...@gmail.com> wrote: > >> > > >> > I have been working on a research project where I have been modifying > the runtime such that I can control the goroutines that are scheduled as > well as get access to the values of program variables. > >> > I know I can access the stack through the g struct for a goroutine > but I was wondering if someone could tell me how to get the symbol/object > table so that I can figure out the names of the local variables on the > stack for the goroutine as well as the variables on the heap. > >> > Any help would be greatly appreciated. > >> > >> The names of local variables on the stack are recorded only the debug > >> information, which is not loaded into memory. You would need to > >> locate the binary, open it, and look at the debug info. Getting a > >> local variable name from the debug info is complex, but Delve and gdb > >> manage to do it. > >> > >> That is, getting the names of local variables is technically possible > >> but quite hard. I wouldn't recommend this approach. > >> > >> 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 golan...@googlegroups.com <javascript:>. > > For more options, visit 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.
