code review 5168046: documentation: Debugging Go code with GDB tutorial.

documentation: Debugging Go code with GDB tutorial.

[lvd1, 2011-10-01 00:07:31]

Hello adg@golang.org (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[cw, 2011-10-01 05:49:05]

Might want to mention

  p slice[..] doesn't always work (yet)

  (try it on a string for example)


  p localVar before it's encountered/initialized shows garbage (i guess gdb
can't robustly tell when it's scope starts)


  b line (that has no code for it) doesn't actually do anything useful


when looking at goroutines which have been created but never scheduled (ie.
under a debugger this might happen) their PC state is usually runnable
runtime.goexit

[lvd1, 2011-10-01 08:55:04]

thanks for your feedback. all valid points.

On Fri, Sep 30, 2011 at 22:49, <cw@f00f.org> wrote:

> Might want to mention
>
>  p slice[..] doesn't always work (yet)
>
>  (try it on a string for example)
>
>
>  p localVar before it's encountered/initialized shows garbage (i guess
> gdb can't robustly tell when it's scope starts)
>


>  b line (that has no code for it) doesn't actually do anything useful
>
>
should set breakpoint just before the next actual code.  if you have an
example where it doesn't please fwd.


>
> when looking at goroutines which have been created but never scheduled
> (ie. under a debugger this might happen) their PC state is usually
> runnable runtime.goexit
>
>
>
>
http://codereview.appspot.com/**5168046/<http://codereview.appspot.com/5168046/>
>

[lvd1, 2011-10-01 16:56:38]

On Sat, Oct 1, 2011 at 01:54, Luuk van Dijk <lvd@golang.org> wrote:

> thanks for your feedback. all valid points.
>
> On Fri, Sep 30, 2011 at 22:49, <cw@f00f.org> wrote:
>
>> Might want to mention
>>
>>  p slice[..] doesn't always work (yet)
>>
>
Explained, plus workaround


>
>>  (try it on a string for example)
>>
>>
>>  p localVar before it's encountered/initialized shows garbage (i guess
>> gdb can't robustly tell when it's scope starts)
>>
>
>
Added


>
>>  b line (that has no code for it) doesn't actually do anything useful
>>
>>
> should set breakpoint just before the next actual code.  if you have an
> example where it doesn't please fwd.
>
>
>>
>> when looking at goroutines which have been created but never scheduled
>> (ie. under a debugger this might happen) their PC state is usually
>> runnable runtime.goexit
>>
>>
>>
Not sure what useful things i could say about the goroutine state, but
suggestions are welcome, as are suggestions for modifications to the GDB/Go
Runtime support to print things that would really help in real-world
debugging situations.


>
>>
http://codereview.appspot.com/**5168046/<http://codereview.appspot.com/5168046/>
>>
>
>

[cw, 2011-10-02 04:45:30]

LGTM

http://codereview.appspot.com/5168046/diff/11001/doc/debugging_with_gdb.html
File doc/debugging_with_gdb.html (right):

http://codereview.appspot.com/5168046/diff/11001/doc/debugging_with_gdb.html#...
doc/debugging_with_gdb.html:451: The extension functions $len and $cap work on
strings, arrays and slices:
$cap doesn't work on strings

[cw, 2011-10-02 04:56:18]

> Not sure what useful things i could say about the goroutine state,
> but suggestions are welcome, as are suggestions for modifications to
> the GDB/Go Runtime support to print things that would really help in
> real-world debugging situations.

(more long term)

i think it would be nice to get more natural slice printing working,
as well a derived types (type myInt int)

i'm not sure how much work that would be inside of gdb and how the
mantainers there would feel about that

certainly not a priority

[lvd1, 2011-10-02 05:43:01]

On Sat, Oct 1, 2011 at 21:56, Chris Wedgwood <cw@f00f.org> wrote:

> > Not sure what useful things i could say about the goroutine state,
> > but suggestions are welcome, as are suggestions for modifications to
> > the GDB/Go Runtime support to print things that would really help in
> > real-world debugging situations.
>
> (more long term)
>
> i think it would be nice to get more natural slice printing working,
> as well a derived types (type myInt int)
>
> i'm not sure how much work that would be inside of gdb and how the
> mantainers there would feel about that
>
> certainly not a priority
>

I just talked to one of the gdb maintainers.  currently the language Go has
it's dwarf enum, but gdb just falls back to the C handler for language
specific things.  The longer term solution would be to have a real go
variant. It's on the agenda, which is a
latin word for '[list of things] to do' :-)

[adg, 2011-10-04 15:38:21]

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html
File doc/debugging_with_gdb.html (right):

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html#n...
doc/debugging_with_gdb.html:218: <code>'regexp.*Regexp·doParse'</code>. (Note
that the second dot is a "middot,"
Is this still the case with the middot? I thought rsc said not.

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html#n...
doc/debugging_with_gdb.html:250: Execution has paused at the breakpoint. Then
see which goroutines are running, and what they're doing:
\n</p> after "breakpoint."
<p>
See which goroutines...

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html#n...
doc/debugging_with_gdb.html:260: the one marked with the '*' is the current
goroutine.
wrap '*' with <code></code>

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html#n...
doc/debugging_with_gdb.html:280: The other goroutine, number 1, is stuck in
gosched, blocked on a channel read:
s_gosched_<code>runtime.gosched</code>_
s_read_receive (<code>runtime.chanrecv</code>_

http://codereview.appspot.com/5168046/diff/11001/doc/debugging_with_gdb.html
File doc/debugging_with_gdb.html (right):

http://codereview.appspot.com/5168046/diff/11001/doc/debugging_with_gdb.html#...
doc/debugging_with_gdb.html:318: dangerous to use, since it will also try to
print uninitialized variables. Uninitialized slices may cause gdb to try
s_gdb_GDB_

http://codereview.appspot.com/5168046/diff/11001/doc/debugging_with_gdb.html#...
doc/debugging_with_gdb.html:319: to print arbitrary large arrays.
s/arbitrary/arbitrarily/

http://codereview.appspot.com/5168046/diff/11001/doc/debugging_with_gdb.html#...
doc/debugging_with_gdb.html:334: on the right-hand side of the type name and
made up a 'struct' keyword, in traditional C style.
s_'struct'_<code>'struct'</code>_

http://codereview.appspot.com/5168046/diff/11001/doc/debugging_with_gdb.html#...
doc/debugging_with_gdb.html:393: (gdb) bt
dupe line

[lvd, 2011-10-04 18:08:49]

all done.  i ran all tests and nothing broke!

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html
File doc/debugging_with_gdb.html (right):

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html#n...
doc/debugging_with_gdb.html:218: <code>'regexp.*Regexp·doParse'</code>. (Note
that the second dot is a "middot,"
On 2011/10/04 15:38:21, adg wrote:
> Is this still the case with the middot? I thought rsc said not.

Done.

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html#n...
doc/debugging_with_gdb.html:250: Execution has paused at the breakpoint. Then
see which goroutines are running, and what they're doing:
On 2011/10/04 15:38:21, adg wrote:
> \n</p> after "breakpoint."
> <p>
> See which goroutines...

Done.

http://codereview.appspot.com/5168046/diff/7001/doc/debugging_with_gdb.html#n...
doc/debugging_with_gdb.html:280: The other goroutine, number 1, is stuck in
gosched, blocked on a channel read:
On 2011/10/04 15:38:21, adg wrote:
> s_gosched_<code>runtime.gosched</code>_
> s_read_receive (<code>runtime.chanrecv</code>_

Done.

[adg, 2011-10-05 17:49:51]

*** Submitted as http://code.google.com/p/go/source/detail?r=320d83ed794a ***

documentation: Debugging Go code with GDB tutorial.

R=adg, cw, lvd
CC=golang-dev
http://codereview.appspot.com/5168046

Committer: Andrew Gerrand <adg@golang.org>