cmd/compile: Debug information missing : no stack info , no variables info using gdb

[gopherbot]

by guybrandw:

Since version 1.3 , I cant get debugging information .
using both linux64 , windows64/32 :
1. the variables displays values with no correlation to the real value (fmt.Print()
displays the right values) .
2. the call stack displays only the last step of the stack , other steps are displayed
as ???? .

I have uninstalled Go 1.3 , installed 1.21 and both problems were "solved" .
reinstalled 1.3 , the problem returned .

attached prinshots of simple code , the variables displayed in LiteIde , the stack , and
print function of the gdb .

to make sure , I have tried the same installing the Zues IDE , same problems reproduced .

Attachments:

1. debugIssue.png (37441 bytes)

[ianlancetaylor]

Comment 1:

Note the beginning of http://golang.org/doc/gdb .

Labels changed: added repo-main, release-none, gdb.

[gopherbot]

Comment 2 by guybrandw:

Thanks very much on the fast reply .
SO , just to see that I understand correctly :
If GO 1.2.1 does show the debug info , and GO 1.3 does not
is there no other way to see it , any alternative for the gdb ? is there any big
differences between gc / gcc ?
or to sum it up , are my alternatives using fmt.Print every other line , or using 1.2.1 ?
Thanks .

[robpike]

Comment 3:

The report is unclear but there's definitely something funny going on. Given the snippet
in the image I wrote this file:
http://play.golang.org/p/islHo1hsMN
package main
import (
    "fmt"
)
func main() {
    a := 6
    fmt.Println(a)
    sub(a)
}
func sub(a int) {
    a = 7
    subsub(a)
}
func subsub(a int) {
    a = 8
    fmt.Println(a)
}
I compiled it at tip (1.3+) and at 1.2, and then ran gdb and set a breakpoint at
'main.subsub'. With 1.3, bt prints
#0  main.subsub (a=7) at /home/r/bug.go:18
#1  0x0000000000400cce in main.sub (a=7) at /home/r/bug.go:15
#2  0x0000000000400c8f in main.main () at /home/r/bug.go:10
while with 1.2, bt prints
#0  main.subsub (a=7) at /home/r/bug.go:18
#1  0x0000000000400cc9 in main.sub (a=6) at /home/r/bug.go:15
#2  0x0000000000400c92 in main.main () at /home/r/bug.go:10
Note the argument to sub has changed value between the two prints.

[gopherbot]

Comment 4 by guybrandw:

OK , at least your values make "some sense" , I'm getting a real awkward value (1 !!)
what OS are you on / what GO build , what GBD build , GCC flags ?
any suggestions on using something other than gdb ?
I've been actually thinking about building some tool, but I don't see how I do that
without altering the code (not enough support in runtime/debug to integrate to the
runtime's variables , or am I missing something ?)
 Thanks .

[gopherbot]

Comment 5 by ziyouchutuwenwu:

i have the same problem, version 1.22 show vars ok, 1.3 not work, sometime could not
break on source file

[gopherbot]

Comment 6 by ignatovs:

The same issue for me.

[gopherbot]

Comment 7 by simon.ishai:

Hi,
Same thing happened to me as well (windows 32/64)
Version 1.2.1 showed vars and stack in a proper way, but after I've upgraded to the
version 1.3, the debug info became unavailable.
I hope that this issue will get more attention, because it is very unconvenient
situation which holds me from upgrading my setup to the newest version (now 1.3.1)
Simon

[gopherbot]

Comment 8 by ben.lubar:

With go1.3.3 linux/amd64 using the same steps as r:
#0  main.subsub (a=7) at [omitted]/main.go:18
#1  0x0000000000400cce in main.sub (a=4197519) at [omitted]/main.go:15
#2  0x0000000000000007 in ?? ()
#3  0x0000000000400c8f in main.main () at [omitted]/main.go:10

[gopherbot]

Comment 9 by masinuncz:

I Like it
http://nunsite.blogspot.com/2014/10/beberapa-kelebihan-dan-kekurangan-iphone-6.html

[gopherbot]

Comment 10 by anneagile:

I'm  concerned that this issue is from July but still says 'New' despite that numerous
people have reproduced it. How would that status be changed? Are there enough
maintainers to read the tickets? 
I'm  new so I'm trying to get a sense of how fast the project is moving/fixing things.
Debugging is always on my hot list, so here I am. :)
thank you! 
Anne
ps  Remark #9 might be a spam post.

[ianlancetaylor]

Comment 11:

The project is moving fast and fixing things, but gdb support is a known problem area. 
See http://golang.org/doc/gdb .  I don't know of anybody actively working on improving
the debug info.

Status changed to Accepted.

[gopherbot]

Comment 12 by guybrandw:

Do you have an alternative to suggest ?
Debugging is a fundamental issue ...

[minux]

Comment 13:

debugging is a fundamental issue, but
debugging using gdb is not.
also, in a concurrent setting, stop the
world debugging is not suitable anyway.

[gopherbot]

Comment 14 by guybrandw:

So what do you suggest instead ?

[gopherbot]

Comment 15 by peter@dalinis.com:

https://github.com/derekparker/delve/
I have been using this, and it works well enough for me.

[gopherbot]

Comment 16 by guybrandw:

Thanks , I will try it with the Linux debugging , any similar options for OSX and/or
windows debugging ?

[gopherbot]

Comment 17 by peter@dalinis.com:

The author of delve has an open ticket for osx support.  No idea for
Windows.

[gopherbot]

Comment 18 by eidmanna:

Debugging somehow is very essential!!!
Is is possible to use this debugger https://github.com/derekparker/delve/ in combination
with liteide https://github.com/visualfc/liteide?