Comment 1 by joelgwebber:

To add a bit more color -- there are two separate-but-related issues here: stepping
*into* a call-through-function-pointer, and stepping *out* of a function so invoked.
With normal compiler flags (none, or just -N) stepping in actually works fine. Stepping
out is what confuses gdb in this case, and the only solution is to use "bt" to figure
out how you got where you are, then you need to set a breakpoint in the caller and
"c"ontinue.
Compiling with -l (disable inlining) breaks stepping in as well. In this case, gdb takes
you directly into the thunk rather than into the callee. From here you can only "stepi"
your way into the callee. Stepping out is broken as before.

Comment 2:

one way to solve that is to use gdb's jit interface
http://sourceware.org/gdb/current/onlinedocs/gdb/Registering-Code.html#Registering-Code
but i'm afraid it's much too heavy weight for our use case, maybe we just change closure
repr.
into a pointer pair (code_ptr, env_ptr) and then this will no longer be a problem
(additional
benefit would be more secure Go binaries with no writable&executable sections).
just a side note, misc/cgo/test has code that assumes the current presentation of
closures.

Comment 3:

Gcc uses the same technique for nested functions (an extension to C), and gdb seems to
work OK in that case.  That would be a possible avenue of investigation.

Comment 5:

Labels changed: added priority-later, removed priority-triage.

Comment 6:

Labels changed: added go1.1.

Comment 7:

Labels changed: added size-l.

Comment 9:

Owner changed to @rsc.

Comment 10:

This issue was closed by revision b1b67a3.

Status changed to Fixed.