gdb: nothing works (windows amd64)

[gopherbot]

by SmileKZS:

## What steps will reproduce the problem?

1. https://gist.github.com/smilekzs/5640921
2. go build test.go
3. gdb test.exe
4. run the following

```
(gdb) break main.main
(gdb) r
(gdb) n
(gdb) n
(gdb) n
(gdb) p s
(gdb) p S
(gdb) p I
(gdb) info goroutines
```

## What is the expected output?

Print value of `s`, `S`, and `I`
List goroutines.

## What do you see instead?

```
(gdb) p s
No symbol "s" in current context.
(gdb) p S
No symbol "S" in current context.
(gdb) info goroutine
```

Then it crashes.

## Which compiler are you using (5g, 6g, 8g, gccgo)?

go build test.go
(6g I suppose?)

##Which operating system are you using?

Windows 8 amd64.
Same results on two windows 8 boxes.

## Which version are you using?  (run 'go version')

go version go1.1 windows/amd64

## Please provide any additional information below.

* Go 1.1, official windows amd64 msi installer.
* Python 2.6, official installer.
* GDB 7.4 amd64 with python26 support, from
https://code.google.com/p/go-w64/downloads/list
* Environment properly set.

Workaround batch script for https://golang.org/issue/5458 :
https://gist.github.com/smilekzs/5640649

BTW: It's really hard to find a working GDB amd64 binary with Python support. Before I
even hit this bug, there's the necessity of a workaround (otherwise GDB can't even find
the runtime sources -- see issue #5458 for details). How can we have no first-class
debug tool that Just Works?

[alexbrainman]

Comment 1:

Did you read http://golang.org/doc/gdb ?
In particular: " ... optimizations can sometimes make debugging with gdb harder. To
disable them when debugging, pass the flags -gcflags "-N -l" to the go command used to
build the code being debugged."
Alex

[gopherbot]

Comment 2 by SmileKZS:

Sorry -- I didn't include the flags while I should have.
Nevertheless the problem persists.
```
C:\Users\xxxxxxxx\Desktop>go build -gcflags "-N -l" test.go
C:\Users\xxxxxxxx\Desktop>gdb test.exe
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from C:\Users\xxxxxxxx\Desktop/test.exe...done.
Loading Go Runtime support.
(gdb) break main.main
Breakpoint 1 at 0x401000: file C:/Users/xxxxxxxx/Desktop/test.go, line 5.
(gdb) r
Starting program: C:\Users\xxxxxxxx\Desktop/test.exe
[New Thread 3900.0x133c]
Breakpoint 1, main.main () at C:/Users/xxxxxxxx/Desktop/test.go:5
5       func main() {
(gdb) n
6               println(S)
(gdb)
[New Thread 3900.0x11ac]
1234
7               S = S + "5"
(gdb)
8               println(S)
(gdb) p S
No symbol "S" in current context.
(gdb) info goroutines
```
then crashes.

[alexbrainman]

Comment 3:

P is not local variable, it is defined inside package main. Try "p main.S" instead of "p
S".
I don't know about "... then crashes".
Alex

[gopherbot]

Comment 4 by SmileKZS:

I did try this, though.
```
(gdb) p main.S
Attempt to extract a component of a value that is not a structure.
```
Yes -- after `info goroutines` it crashes without any information emitted.

[minux]

Comment 5:

p 'main.S'
as main.S is the symbol name.

[gopherbot]

Comment 6 by SmileKZS:

@minux
Yes this works now. At last!
However `info goroutines`, or `p $len('main.s')` still crashes. Any idea?

[minux]

Comment 7:

@alex.brainman, can you reproduce the crash on windows?
debugging the program on darwin does indicate there is a problem:
when i do this:
b 'main.main'
r
n
n
n
p s
gdb hangs (even if i don't source runtime-gdb.py).

[minux]

Comment 8:

note: to debug the program you need to compile it with
go build -gcflags "-N -l" test.go

[gopherbot]

Comment 9 by SmileKZS:

@minux
I've tested both with and without `-gcflags "-N -l"` on two Windows 8 amd64 boxes. All
crashes I encounter seem to be caused by python interop.

[alexbrainman]

Comment 10:

minux,
Here is my gdb session:
C:\go\path\mine\src\t>c:\bin\gdb.exe main.exe
GNU gdb (GDB) 7.5.50.20130118
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;.
This binary was built by Equation Solution <http://www.Equation.com>;...
Reading symbols from C:\go\path\mine\src\t\main.exe...done.
(gdb) b 'main.main'
Breakpoint 1 at 0x401000: file C:/go/path/mine/src/t/main.go, line 6.
(gdb) r
Starting program: C:\go\path\mine\src\t\main.exe
[New Thread 1536.0x5c4]
Breakpoint 1, main.main () at C:/go/path/mine/src/t/main.go:6
6       func main() {
(gdb) n
7               go print(I)
(gdb) n
[New Thread 1536.0x1c8c]
8               s := S
(gdb) n
9               print(s)
(gdb) p s
$1 = 0x420cb8 "abc"
(gdb)

[robpike]

Comment 11:

We could use a gdb expert.

Labels changed: added go1.3maybe, expertneeded.

Status changed to Accepted.

[robpike]

Comment 12:

Labels changed: removed go1.3maybe.

[rsc]

Comment 13:

Labels changed: added go1.3maybe.

[rsc]

Comment 14:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 15:

Labels changed: added repo-main.

[robpike]

Comment 16:

Labels changed: added gdb.