watchpoint on "private" variables with Gdb

[Basile Starynkevitch]

Hello all,

I'm debugging the 5d6c770eb29ae0a33 commit of my monimelt program on github.
I don't understand very well how init functions work (and I probably don't understand the order in which init functions are running, notably with init functions in several files of the same package).

I'm declaring in file objvalmo/objvalmo.go the following package private variables:

var glovar_map map[string]**ObjectMo
var glovar_regexp *regexp.Regexp
var glovar_mtx sync.Mutex

And the init function is supposed to initialize them: const glovar_regexp_str = `^[a-zA-Z_][a-zA-Z0-9_]*$` func init() {     glovar_map = make(map[string]**ObjectMo)     glovar_regexp = regexp.MustCompile(glovar_regexp_str) }   For some reason (probably my misunderstanding or bug), the glovar_map variable is not initialized like I want it to be. BTW, it is filled in RegisterGlobalVariable function (same file). And that function gets called in the init function of file globals.go of the same package. So I wanted to use a GDB watchpoint on that glovar_map. Sadly, the ELF name of that variable is objjvalmo.glovar_map with some internal dot in the name: ~/monimelt % nm bin/monimelt|grep glovar           000000000097a7f8 b objvalmo.glovar_map 00000000009990e8 b objvalmo.glovar_mtx 000000000097a800 b objvalmo.glovar_regexp and of course when I type watch objvalmo.glovar_map in gdb it does not know that variable (because gdb is interpreting the dot as a field separator). Any tricks for GDB to avoid this confusion? If you need to reproduce my bug run bin/monimelt -tiny-dump1 /tmp/foo inside the gdb debugger (in the directory containing README.md). FWIW, my Go is 1.8 on Linux/Debian/Sid/x86-64, I'm building with gb, and gdb is 7.12 and is reading the /usr/local/go/src/runtime/runtime-gdb.py script. (I would wish that Go would mangle names with a dollar, not a dot) Cheers. -- Basile Staynkevitch, France ; email: bas...@starynkevitch.net

[Ian Lance Taylor]

On Sat, Mar 11, 2017 at 10:45 AM, Basile Starynkevitch <bas...@starynkevitch.net> wrote:

Hello all,

I'm debugging the 5d6c770eb29ae0a33 commit of my monimelt program on github.
I don't understand very well how init functions work (and I probably don't understand the order in which init functions are running, notably with init functions in several files of the same package).

I'm declaring in file objvalmo/objvalmo.go the following package private variables:

var glovar_map map[string]**ObjectMo
var glovar_regexp *regexp.Regexp
var glovar_mtx sync.Mutex

And the init function is supposed to initialize them: const glovar_regexp_str = `^[a-zA-Z_][a-zA-Z0-9_]*$` func init() {     glovar_map = make(map[string]**ObjectMo)     glovar_regexp = regexp.MustCompile(glovar_regexp_str) }   For some reason (probably my misunderstanding or bug), the glovar_map variable is not initialized like I want it to be. BTW, it is filled in RegisterGlobalVariable function (same file). And that function gets called in the init function of file globals.go of the same package. So I wanted to use a GDB watchpoint on that glovar_map. Sadly, the ELF name of that variable is objjvalmo.glovar_map with some internal dot in the name: ~/monimelt % nm bin/monimelt|grep glovar           000000000097a7f8 b objvalmo.glovar_map 00000000009990e8 b objvalmo.glovar_mtx 000000000097a800 b objvalmo.glovar_regexp and of course when I type watch objvalmo.glovar_map in gdb it does not know that variable (because gdb is interpreting the dot as a field separator). Any tricks for GDB to avoid this confusion? If you need to reproduce my bug run bin/monimelt -tiny-dump1 /tmp/foo inside the gdb debugger (in the directory containing README.md).

watch 'objvalmo.glovar_map'

That is, use single quotes to tell gdb that the '.' is part of the name.

When a package has multiple init functions, the init functions in one file are executed in source file order, and init functions in two files are executed in the alphabetical order of the file names.

Ian