code review 69870049: doc: Update doc/gdb to reflect current gdb support.

doc: Update doc/gdb to reflect current gdb support.

The change shrinks debugging_with_gdb.html down to the parts that are
still relevant and accurate for 1.3:
- Added a section on single-stepping Go programs (explanation why
it doesn't work, and tips to get around that).
- Removed mention of runtime-gdb.py and the gdb extensions in there.
- Removed `bt`, `info locals`, `info variables`, `info args`,
which don't work as expected.
- Removed the tutorial. Debugging regexp.test will SIGSEGV,
and most of the steps in the tutorial no longer work.

It's a big change, but it's the honest truth of current gdb support.

[dlsniper, 2014-03-05 09:23:59]

Hi,


Since I've recently added support for gdb + go in IntelliJ IDEA
(http://goo.gl/qdWzqW) I did spent quite some time on this topic.

Saying that improved support for go can be found in gdb 7.6+ will help in some
cases.

The docs should say that gdb support is experimental and that things are not
stable yet but removing so many things that work from the docs doesn't really
make sense imo.

Cheers

https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.html
File doc/debugging_with_gdb.html (left):

https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
doc/debugging_with_gdb.html:48: Show backtraces and unwind stack frames:
This part (bt and frames) worked for me always so far.

https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
doc/debugging_with_gdb.html:70: A recent extension mechanism to GDB allows it to
load extension scripts for a
This is still useful for some people, especially when go is not installed into
the default location. Please revert this.

https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
doc/debugging_with_gdb.html:115: If you're interested in what the debugging
information looks like, run
Why is this removed?

https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
doc/debugging_with_gdb.html:134: <h2 id="Tutorial">Tutorial</h2>
The tutorial works ok and I see no reason to remove it just because some other
things are broken. I do believe that maybe the docs should say that gdb support
is experimental but removing this is not good imo.

Also, the section provides a nice tutorial for quickly getting up and running
with gdb (and not only) go.

[graham_king, 2014-03-06 04:49:41]

Thanks for the feedback.

On 2014/03/05 09:23:59, dlsniper wrote:
> 
> Saying that improved support for go can be found in gdb 7.6+ will help in some
> cases.
> 

I added mention of native Go support, and link to the GDB manual Go page.

> The docs should say that gdb support is experimental and that things are not
> stable yet but removing so many things that work from the docs doesn't really
> make sense imo.

I don't think experimental is the right word. That implies gdb support is going
to improve.

> 
> Cheers
> 
> https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.html
> File doc/debugging_with_gdb.html (left):
> 
>
https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
> doc/debugging_with_gdb.html:48: Show backtraces and unwind stack frames:
> This part (bt and frames) worked for me always so far.
> 

Backtraces don't work for me. Here's an example of what I get (Ubuntu 13.04, gdb
7.6.1, latest Go head):

(gdb) l
1       package main
2
3       func main() {
4               println(one())
5       }
6
7       func one() int {
8               return two()
9       }
10
(gdb) l
11      func two() int {
12              a := 42
13              return a
14      }
(gdb) b 12
Breakpoint 1 at 0x400cb1: file /home/graham/s3.go, line 12.
(gdb) r
Starting program: /home/graham/s3 

Breakpoint 1, main.init () at /home/graham/s3.go:12
12              a := 42
(gdb) bt
#0  main.init () at /home/graham/s3.go:12
#1  0x000000000040eb1a in runtime.main () at
/home/graham/src/go/src/pkg/runtime/compiler.go:1
#2  0x0000000000455990 in runtime.sysargs ()
#3  0x0000000000000000 in ?? ()


>
https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
> doc/debugging_with_gdb.html:70: A recent extension mechanism to GDB allows it
to
> load extension scripts for a
> This is still useful for some people, especially when go is not installed into
> the default location. Please revert this.
> 

runtime-gdb.py doesn't do anything useful when you load it. I put an example of
what you get if you restore it, in issue 6963, on Mar 1.

>
https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
> doc/debugging_with_gdb.html:115: If you're interested in what the debugging
> information looks like, run
> Why is this removed?
> 

6.out won't mean anything to people using the 'go' tool (rather than 6g/8g etc
directly). I didn't update it because I didn't think browsing dwarf / elf
sections was relevant to this page. I agree it's interesting to poke around in
there though. Do you think I should put it back?

>
https://codereview.appspot.com/69870049/diff/20001/doc/debugging_with_gdb.htm...
> doc/debugging_with_gdb.html:134: <h2 id="Tutorial">Tutorial</h2>
> The tutorial works ok and I see no reason to remove it just because some other
> things are broken. I do believe that maybe the docs should say that gdb
support
> is experimental but removing this is not good imo.
> 
> Also, the section provides a nice tutorial for quickly getting up and running
> with gdb (and not only) go.

The tutorial does not work for me. I get a SIGSEGV:

Reading symbols from /home/graham/src/go/src/pkg/regexp/regexp.test...done.
(gdb) b 'regexp.TestFind'
Breakpoint 1 at 0x43d3c5: regexp.TestFind. (2 locations)
(gdb) run
Starting program: /home/graham/src/go/src/pkg/regexp/regexp.test 
[New LWP 13095]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 13095]
0x000000000043d3e1 in regexp.TestFind (t=0xc2080473b0) at
/home/graham/src/go/src/pkg/runtime/print.c:345
345             gwrite(buf+i, nelem(buf)-i);

[graham_king, 2014-03-06 05:06:59]

Hello florinpatan@gmail.com (cc: golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[gobot, 2014-03-06 17:34:04]

R=r@golang.org (assigned by josharian@gmail.com)

[r, 2014-04-26 15:09:38]

I agree with dlsniper that this change goes too far. Gdb often works fine; your
changes imply it almost never does. It's a shame that gdb has so much trouble
with threading, but for many uses that's not an issue.

 I propose to put a somewhat different disclaimer at the top of the file but
leave the rest alone.

[gobot, 2014-06-16 19:59:33]

R=close (assigned by r@golang.org)